In the lines below:
These are the two methods of getting the classloaders
1) Thread.currentThread().getContextClassLoader();
2) getClass().getClassLoader();
Would anybody please explain me the difference between these two.
Also my second question is when do we use Thread.currentThread().getContextClassLoader()
I have already refered some post on StackOverflow regarding the same, but didn't find the fundamental answer.
I have seen the answer of the question you suggested.
Difference between thread's context class loader and normal classloader
Thread context classloaders provide a back door around the classloading delegation scheme. Take JNDI for instance: its guts are implemented by bootstrap classes in rt.jar (starting with J2SE 1.3), but these core JNDI classes may load JNDI providers implemented by independent vendors and potentially deployed in the application's -classpath. This scenario calls for a parent classloader (the primordial one in this case) to load a class visible to one of its child classloaders (the system one, for example). Normal J2SE delegation does not work, and the workaround is to make the core JNDI classes use thread context loaders, thus effectively "tunneling" through the classloader hierarchy in the direction opposite to the proper delegation.
As it is suggested that the workaround is to make the core JNDI classes use thread context loaders, I didn't understand how this helps in this case.
We want to load the implementation vendor classes using parent classloader but they are not visible to parent classloader. So how can we load them using parent, even if we set this parent classloader in context classloader of thread.
Please suggest
