Factor out the thread pool alone so that any client can use it, not
just the ORB? And initialize it in its own thread at startup (always)?
On Apr 27, 2007, at 12:32 AM, Ken Cavanaugh wrote:
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>