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
