Instead of setting the saved ClassLoader to the value at the time of the
thread creation, we need to set it to a known good value. I think the best
place to do this is in the ThreadPoolImpl constructor. All that we need
to do is save the value of Thread.currentThread().getContextClassLoader()
(called with a doPrivileged block if the SecurityManager is non-null)
in the constructor so that the context ClassLoader can be restored to this
saved value in the WorkerThread run method. This is a really simple change:
The WorkerThread class is an inner class in ThreadPoolImpl, so we can
just move
all of the workerThreadClassLoader methods and data from WorkerThread
to ThreadPoolImpl. The worker thread already calls setClassLoader
near the end of its run() method.
However, there be a problem with this approach. The App server's thread
pool gets
created when ORBManager.getORB is called. getORB is NOT called at server
start time when on-demand initialization is used. Does anyone know if
we can
depend on having a context ClassLoader that is permanent when on-demand
initialzation takes place? Or is it possible that a web app could trigger
on-demand initilization of the ORB by accessing an EJB, and then later
be undeployed,
leading to an even harder to find variant of the problem we already have?
If this can occur, we will have to either add a place to explicitly
obtain the correct
ClassLoader which is established at app server start time,
or perhaps simply set the saved context ClassLoader to null.
But I don't know whether a null context ClassLoader is reasonable or not.
Nothing in the Java docs seems to address this, and a simple standalone Java
app has sun.misc.Launcher$AppClassLoader set as the default context
ClassLoader.
Thanks,
Ken.