On Saturday 03 January 2004 04:43, Noel J. Bergman wrote:
> Niclas Hedhman wrote:
> > The rationale/intention behind this design is a bit flawed, but
> > centers around assigning the Block Classloader to the Thread's
> > ContextClassloader, but the intention is not fulfilled...
>
> Would the easiest change be to set it up so that a Block's Classloader is
> assigned to a Thread's ContextClassloader when dispatching that thread from
> a pool to perform work on that Block?
1. No new thread for each Block.
2. A debate whether the Thread's ContextClassLoader should actually be set to
the Block's classloader, before any call to the LifeCycle methods and/or any
call to the service interface methods.
Argument in favour of NOT doing 2.
==================================
Any code that tries to locate resources, images, classes, resource bundles or
whatever, should do;
ClassLoader cl = this.getClass().getClassLoader();
This ALWAYS guarantees that the resources assoicated with the Block/component
is available in the expected way.
It also leave the ContextClassLoader usage open for "other things", for
instance, global resources, resources defined in a "context" such as a
servlet environment, and so on.
Argument in favour of doing 2.
==============================
So far I have only heard "people normally does;"
ClassLoader cl = Thread.currentThread().getContextClassLoader();
But this is partly true in non-well-defined classloading architectures, where
often the "component" belongs to a higher level classloader, but is passed
"stuff" which resides in lower level Classloaders, for instance, Swing is
part of the Bootstrap classloader, and when it is given a new L&F it must
read resources in that L&F's classloader, which is typically the System
classloader.
So we must ask ourselves;
Do WE have use-cases where "inner blocks" will pass resources/classes/stuff to
its Outer blocks or blocks in other branches??
If we DO have such use-case, things get complicated, because if the Thread
ContextClassloader is set in the Proxy's service interface methods, the above
won't work either. It must then be that the context classloader is ONLY set
at the "lowest" entry level in each container branch. But that will still
makes the resources unreachable across lowest-level components in different
branches.
Bottomline, IMVNSHO, the ContextClassloader SHOULD NOT be set for the
LifeCycle method calls, NOR for the service interface method calls. And that
we MAY discover later what it should be set to, so for now it is left
"undefined" and any usage until then is an explicit "violation of contract".
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
