Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Date: Tue, 30 Sep 2003 23:20:10 -0400 (EDT)
From: Aaron Mulder <ammulder@alumni.princeton.edu>
To: geronimo-dev@incubator.apache.org
Subject: Re: [ClassLoader] What is the TCCL for Twiddle?
In-Reply-To: <Sea1-F118TwctPBjxPG00000d3d@hotmail.com>
Message-ID: <Pine.LNX.4.44.0309302311500.26475-100000@www.princetongames.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

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