Using thread context classloader in Sling

[Unmesh Joshi <un...@gmail.com>]

Hi,

In Sling, org.apache.sling.commons.classloader.impl.ClassLoaderFacade
is set as thread context classloader while activating
JspScriptEngineFactory.
The pseudo code is like following

ClassLoader oldClassLoader = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(jspClassLoader)
try {

....
} finally {

Thread.currentThread().setContextClassLoader(oldClassLoader)

}

Why JSP processing needs to set thread context classloader explicitly?

Its problematic to use any framework (like CXF, or JAX-RPC stubs)
relying on thread context classloader from within OSGI components (and
therefore from sling servlets). Is above idiom a recommended way of
using these frameworks?

Thanks,
Unmesh

Re: Using thread context classloader in Sling

[Felix Meschberger <fm...@adobe.com>]

Hi Unmesh,

We found that some scripting languages implemented in Java depend on the
Thread Context Classloader being set. This is mostly the case when they
do their own classloading...

Generally you wound not have to care for class loading in your scripts,
the environment (the scripting engine as well as the bundles provided in
the OSGi framework) should take care of these issues for you ...

So if you are integrating any non-trivial non-OSGi functionality (mostly
anyhting involving XML ...) you as an integrator should take care to
properly handle classloading such that the users of your provided
bundles won't have to care.

You might want to read Neil Bartlett's blog "OSGi Readiness -- Loading
Classes" [1] on this subject.

Regards
Felix

[1]
http://njbartlett.name/2010/08/30/osgi-readiness-loading-classes.html


Am Freitag, den 11.03.2011, 11:00 +0000 schrieb Unmesh Joshi: 
> Hi,
> 
> In Sling, org.apache.sling.commons.classloader.impl.ClassLoaderFacade
> is set as thread context classloader while activating
> JspScriptEngineFactory.
> The pseudo code is like following
> 
> ClassLoader oldClassLoader = Thread.currentThread().getContextClassLoader();
> Thread.currentThread().setContextClassLoader(jspClassLoader)
> try {
> 
> ....
> } finally {
> 
> Thread.currentThread().setContextClassLoader(oldClassLoader)
> 
> }
> 
> Why JSP processing needs to set thread context classloader explicitly?
> 
> Its problematic to use any framework (like CXF, or JAX-RPC stubs)
> relying on thread context classloader from within OSGI components (and
> therefore from sling servlets). Is above idiom a recommended way of
> using these frameworks?
> 
> Thanks,
> Unmesh