Thread context class loader...

[Stanley M. Ho]

Hi Bryan,

Just let you know. I am currently out of office, and I will follow up
this and the serialization discussions later this week.

- Stanley


Bryan Atsatt wrote:
> The OSGi RFP 83 [1][2] contains Thread context class loader requirements
> that are clearly relevant to this JSR. Based on a great deal of painful
> experience with the use/misuse of the thread context class loader, I
> believe that 277 must address this issue to be successful :^).
>
> I suspect that Thread.get/setContextClassLoader() will need to be
> updated to use a policy based implementation.
>
> At Oracle, in our EE system, we have no choice but to constantly switch
> the TCL as threads are assigned to execute code from one of the many
> possible concurrent applications. We tried various schemes for this,
> with the most obvious being a special delegating loader assigned as the
> TCL. But, due to JVM class caching, delegating loaders must have the
> same lifecycle as those they delegate to, and this is tricky when your
> threads are re-used for many different applications, each of which has
> it's own lifecycle.
>
> Our current solution overrides both the Thread
> get/setContextClassLoader() methods, and uses internal server state to
> determine which actual application loader to return. The state is reset
> each time a request processing thread is returned to the pool
> (Executor.afterExecute()) since application code often changes the TCL
> (without the reset the thread pins the loader).
>
> In an EE world, this approach works quite well since there is a natural
> context for class resolution: the application. This large-grained
> context is easily represented via a TCL, and that loader is then
> unconstrained as to its visibility to other loaders. There is a clear
> context switch opportunity as threads are assigned to execute
> application code or returned to the pool.
>
> In a purely module/bundle based environment there is also a natural
> context: the module/bundle loader. But this is too fine-grained since
> its expressed dependencies frequently won't (and shouldn't statically)
> include SPI implementation classes specified by name. And there is no
> switching boundary--each module/bundle loader must control it's own fate.
>
> Clearly, one answer is to introduce some form of context which enables
> the administrator/developer to broaden the search scope beyond the
> module's natural dependencies. The Equinox "buddy" policy approach is a
> good start, but probably needs some refinement/extension and new APIs.
> For example, Thread get/setContextClassLoader() methods could delegate
> to a policy object:
>
>   interface ContextClassLoader {
>       public ClassLoader get();
>       public ClassLoader set(ClassLoader loader);
>   }
>
> (or even a type that reexports the public methods of ClassLoader to
> enable the policy to search across multiple loaders).
>
> But we need to be very careful about the number and kind of policies we
> support to minimize complexity in what is already an extremely complex
> environment. Oracle's class loader framework has elaborate diagnostic
> machinery built-in, which is called upon constantly to help solve
> problems--there seems to be infinite ways to mis-configure a large
> system of classes. And we *still* run across frameworks that don't even
> use the TCL and so don't work properly in a multi-loader env.
>
> Thoughts?
>
> The RFP also deals with serialization; I'll start another thread on that.
>
> // Bryan
>
> [1] EG Wiki:
> http://gee.cs.oswego.edu:8086/download/attachments/257/rfp-0083-Classloading-and-Marshalling-1.pdf
>
> [2] Public (requires registration):
> http://www.paremus.com/downloads/downloads_engineering.html