On Wed, 1 Oct 2003, gianny DAMOUR wrote:
> I am not sure if I understand really your issue. However, AFAIK classes
> should be loaded first from the ThreadContextClassLoader and if it is fails
> from the default class loader.
My issue is that I run the JSR-88 deployer from the command line,
and try to connect to a running geronimo server. It fails. The problem
is that the static initializer of
o.a.g.remoting.transport.TransportFactory gets and suppresses a
ClassNotFoundException on o.a.g.remoting.transport.async.TransportFactory.
In other words, it is unable to load async.TransportFactory from the TCCL.
If I manually instantiate and register async.TransportFactory
(using Class.forName(...async.TransportFactory).newInstance()) then it
works fine, meaning that the class is on the current class' ClassLoader,
but not on the TCCL. However, this doesn't get me very far because as
soon as I attempt to invoke a MBeanServer method, it fails when
unmarshalling the return, which (via BytesMarshalledObject) also uses the
TCCL. Neither the TransportFactory nor the BytesMarshalledObject attempt
to use the current class' ClassLoader if the TCCL doesn't work.
So my conclusion was that the TCCL isn't set properly, though I
suppose we could also argue that all the code should try Class.forName if
the TCCL doesn't work. In truth, I'd probably prefer not to rely on the
TCCL, since the JSR-88 client may be run within an IDE, and who knows what
the IDE will be doing with the TCCL.
> It means that to load a class dynamically, the first attempt should be:
> Class clazz =
> Thread.currentThread().getContextClassLoader().loadClass(aClassName);
> If it fails, one should try the standard classloader via the standard call:
> Class clazz = Class.forName(aClassName)
> BTW, it should be great to implement such an helper class.
>
> For instance, I have written a Resource Adapter deployer, which configures
> amongst other things the ManagedConnectionFactories of an
> outbound-resourceadapter. To configure them, I use explicitely the
> ThreadContextClassLoader. This TCCL is a ClassSpace defines as the loader of
> my Resource Adapter deployer (this is done by configuring the MBeanMetaData
> related to the Resource Adapter deployer).
>
> If you want, I can send you the source of this deployer as I will not submit
> a patch before 2 days.
I would be interested in seeing the source for this for reasons
unrelated to ClassLoaders; I'm currently trying to get the JSR-88 deployer
to actually deploy applications to a remote server, and I'll want to wire
up my deployer MBean to your RA deployer (or merge them or whatever).
Aaron