How to config Tomcat to retrieve images from an external folder outside webapps(outside the context of tomcat)?

You should add following line in server.xml file

<Context path="/DataRepository" docBase="D:/DataRepository/" />

You must put this context tag inside of HOST tag.

Now you can just access the image present inside your path "D:/DataRepository/".

For Example if your DataRepository folder is having an image image 'sanket.jpg' then you can access it as ,

http://localhost:8080/DataRepository/sanket.jpg

HashSet & HashMap

HashSet:

• HashSet is implementation of Set Interface and extends AbstractSet class
• Uses Hash table to store the elements.
• In Hash set the main thing is that objects which are going to be stored in HashSet must override equals() and hashCode() method so that no duplicate value are stored in our set.
• Contains unique elements only.
• HashSet is slower than HashMap.
• Add method is used to add element in Set. public boolean add(Object o)
• Example : In the HashSet, there must be no duplicate elements.

       HashSet is a set, e.g. {10,20,30}

HashMap:

• HashMap is a implementation of Map Interface and extends AbstractMap class, which maps a key to value.
• It contains only unique elements.
• It may have one null key and multiple null values.
• Basically map Interface has two implementation classes HashMap and TreeMap the main difference is TreeMap maintains order of the objects but HashMap will not.
• HashMap is not synchronized, but collection framework provide methods so that we can make them synchronized if multiple threads are going to access our HashMap and one thread is structurally change our map.
• HashMap is faster than HashSet because unique key is used to access object.
• Put method is used to add element in map. public Object put(Object Key,Object value)
• Example : HashMap there must not be duplicate keys, but it may have duplicate values.

        HashMap is a key -> value (key to value) map, e.g. {a -> 10, b -> 20, c -> 20}

Differences between HashSet and HashMap in Java
HashSet internally uses HashMap to store objects. When add(String) method called it calls HahsMap put(key,value) method where key=String object & value=new Object(Dummy). So it maintain no duplicates because keys are nothing but Value Object. Keys which are used to access/store value objects in HashMap should declared as Final because when it is modified Value object can't be located & returns null.

Why add() Method of HashSet return boolean & put() method of HashMap return values?

HashMap put method: Associates the specified value with the specified key in this map. If the map previously contained a mapping for the key, the old value is replaced.

Return:- the previous value associated with key, or null if there was no mapping for key. (A null return can also indicate that the map previously associated null with key.)

HashSet add method: Adds the specified element to this set if it is not already present. More formally, adds the specified element e to this set if this set contains no element e2 such that (e==null ? e2==null : e.equals(e2)). If this set already contains the element, the call leaves the set unchanged and returns false.

Returns:- true if this set did not already contain the specified element.

Daemon Thread

There are two types of threads user thread and daemon thread. The daemon thread is a service provider thread which runs in background to provide services to the user thread and mostly created by JVM for performing background task like Garbage collection and other house keeping tasks. Its life depends on the user threads i.e. when all the user threads dies, JVM terminates this thread automatically.

Points to remember for Daemon Thread:

• It provides services to user threads for background supporting tasks. It has no role in life than to serve user threads.
• Thread.setDaemon(true) makes a Thread daemon but it can only be called before starting Thread in Java. It will throw IllegalThreadStateException if corresponding Thread is already started and running.
• Its life depends on user threads.
• It is a low priority thread.

Why JVM terminates the daemon thread if there is no user thread remaining?
The sole purpose of the daemon thread is that it provides services to user thread for background supporting task. If there is no user thread, why should JVM keep running this thread. That is why JVM terminates the daemon thread if there is no user thread.

Difference between Daemon and Non Daemon thread in Java
1) JVM doesn't wait for any daemon thread to finish before existing.
2) Daemon Thread are treated differently than User Thread when JVM terminates, finally blocks are not called, Stacks are not unwounded and JVM just exits.

Reflection

Reflection in java provides ability to inspect and modify the runtime behavior of applications. Reflection is one of the advance topic of core java. Using reflection we can inspect a class, interface, enums, get their structure, methods and fields information at runtime even though class is not accessible at compile time. We can also use reflection to instantiate an object, invoke it’s methods, change field values.

Fundamentally, the Reflection API consists of two components: objects that represent the various parts of a class file, and a means for extracting those objects in a safe and secure way. The latter is very important, as Java provides many security safeguards, and it would not make sense to provide a set of classes that invalidated those safeguards.

The first component of the Reflection API is the mechanism used to fetch information about a class. This mechanism is built into the class named Class. The special class Class is the universal type for the meta information that describes objects within the Java system. Class loaders in the Java system return objects of type Class. Up until now the three most interesting methods in this class were:

• forName, which would load a class of a given name, using the current class loader
• getName, which would return the name of the class as a String object,which was useful for identifying object references by their class name
• newInstance, which would invoke the null constructor on the class (if it exists) and return you an object instance of that class of object

The Reflection API is symmetric, which means that if you are holding a Class object, you can ask about its internals, and if you have one of the internals, you can ask it which class declared it. Thus you can move back and forth from class to method to parameter to class to method, and so on. One interesting use of this technology is to find out most of the inter-dependencies between a given class and the rest of the system.

We should not use reflection in normal programming where we already have access to the classes and interfaces because of following drawbacks.

• Poor Performance – Since reflection resolve the types dynamically, it involves processing like scanning the classpath to find the class to load, causing slow performance.
• Security Restrictions – Reflection requires runtime permissions that might not be available for system running under security manager. This can cause you application to fail at runtime because of security manager.
• Security Issues – Using reflection we can access part of code that we are not supposed to access, for example we can access private fields of a class and change it’s value. This can be a serious security threat and cause your application to behave abnormally.
• Exposure of Internals - Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing private fields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.
• High Maintenance – Reflection code is hard to understand and debug, also any issues with the code can’t be found at compile time because the classes might not be available, making it less flexible and hard to maintain.

Example : Invoke method on unknown object

By using reflection, the code can use the object and find out if the object has a method called "print" and then call it.

package reflection; import java.lang.reflect.Method;   public class Reflection { public static void main(String[] args){ Foo f = new Foo();   Method method; try { method = f.getClass().getMethod("print", new Class<?>[0]); method.invoke(f); } catch (Exception e) { e.printStackTrace(); } } }   class Foo { public void print() { System.out.println("Hello World"); } } Output :

Hello World

Read more information on Oracle website.

What is Heap space in Java?

When a Java program started Java Virtual Machine gets some memory from Operating System. Java Virtual Machine or JVM uses this memory for all its need and part of this memory is call java heap memory. Heap in Java generally located at bottom of address space and move upwards. Whenever we create object using new operator or by any another means object is allocated memory from Heap and When object dies or garbage collected ,memory goes back to Heap space in Java.

Some key points :-

• Garbage Collection in Java is carried by a daemon thread called Garbage Collector.
• Before removing an object from memory Garbage collection thread invokes finalize() method of that object and gives an opportunity to perform any sort of cleanup required.
• You as Java programmer can not force Garbage collection in Java. It will only trigger if JVM thinks it needs a garbage collection based on Java heap size.
• There are methods like System.gc() and Runtime.gc() which is used to send request of Garbage collection to JVM but it’s not guaranteed that garbage collection will happen.
• If there is no memory space for creating new object in Heap Java Virtual Machine throws OutOfMemoryError or java.lang.OutOfMemoryError heap space.

Heap Generations for Garbage Collection in Java

Java objects are created in Heap and Heap is divided into three parts or generations for sake of garbage collection in Java, these are called as Young generation, Tenured or Old Generation and Perm Area of heap.

New Generation is further divided into three parts known as Eden space, Survivor 1 and Survivor 2 space. When an object first created in heap its gets created in new generation inside Eden space and after subsequent Minor Garbage collection if object survives its gets moved to survivor 1 and then Survivor 2 before Major Garbage collection moved that object to Old or tenured generation.

Permanent generation of Heap or Perm Area of Heap is somewhat special and it is used to store Meta data related to classes and method in JVM, it also hosts String pool provided by JVM. There are many opinions around whether garbage collection in Java happens in perm area of java heap or not, as per my knowledge this is something which is JVM dependent and happens at least in Sun's implementation of JVM.

What is a query cache in Hibernate?

The query cache is responsible for caching the results and to be more precise the keys of the objects returned by queries. Let us have a look how Hibernate uses the query cache to retrieve objects. In order to make use of the query cache we have to modify the person loading example as follows.

Query query = session.createQuery("from Person as p where p.parent.id=? and p.firstName=?");
query.setInt(0, Integer.valueOf(1));
query.setString(1, "Joey");
query.setCacheable(true); //caches the query
List l = query.list();

You also have to change the hibernate configuration to enable the query cache. This is done by adding the following line to the Hibernate configuration.

<property name="hibernate.cache.use_query_cache">true</property>

Note that the query cache does not cache the state of the actual entities in the result set. It caches only identifier values and results of value type. So the query cache should always be used in conjunction with the second-level cache.

This is an optional feature and requires two additional physical cache regions that hold the cached query results and the timestamps when a table was last updated. This is only useful for queries that are run frequently with the same parameters.

Why String is immutable in Java ?

This is an old yet still popular question. There are multiple reasons that String is designed to be immutable in Java. A good answer depends on good understanding of memory, synchronization, data structures, etc. In the following, I will summarize some answers.

1. Requirement of String Pool

String pool (String intern pool) is a special storage area in Java heap. When a string is created and if the string already exists in the pool, the reference of the existing string will be returned, instead of creating a new object and returning its reference.

If string is not immutable, changing the string with one reference will lead to the wrong value for the other references.

The following code will create only one string object in the heap.

1.String string1 = "abcd";

2.String string2 = "abcd";

Here is how it looks:

2. Allow String to Cache its Hashcode

The hashcode of string is frequently used in Java. For example, in a HashMap. Being immutable guarantees that hashcode will always the same, so that it can be cashed without worrying the changes.That means, there is no need to calculate hashcode every time it is used. This is more efficient.

3. Security & Thread Safety.

String is widely used as parameter for many java classes, e.g. network connection, opening files, etc. Were String not immutable, a connection or file would be changed and lead to serious security threat. The method thought it was connecting to one machine, but was not. Mutable strings could cause security problem in Reflection too, as the parameters are strings.

Consider a scenario, in a banking application for money transfer - the beneficiary account number is defined in a string as "0123456789". If by mistake/intentionally this acc. number is changed, money will go to a wrong account.

Here is a code example:

1.boolean connect(string s){

2.if (!isSecure(s)) {

3.throw new SecurityException();

4.}

5.//here will cause problem, if s is changed before this by using other references.   

6.causeProblem(s);

7.}