Ant Classloader - Context Classloader

[Daniel Hoppe <ho...@sitewaerts.de>]

Hi all,

I just wrote my first custom task (big compliment to the Ant architects - it
was really easy and straightforward!) and have some questions regarding
classloading.

My task calls a class ("foo.class") which connects to an application server
and performs some bulk operations. Therefore I need to perform a JNDI lookup
to the server within foo. My task class is in the Ant lib directory and
included by a taskdef. If I include foo into the jar I have the following
situation:

- foo is in the ant library classpath / system classpath
- The JNDI InitialContextfactory of my application server needs to be in the
same classpath as well. If it's in a nested classpath element it  won't be
found from the classloader which loaded foo as that classloader is higher in
the hierarchy
- Therefore I'd need to put all application server classes into the system
classpath what I don't really like.

If I don't include foo into the jar but make my task use a nested classpath
attribute, I cannot directly reference foo as it is not in the system
classpath. I need to perform some heavy reflection to create an instance.
This works fine, but I wonder if there is a nicer approach.

If foo is loaded from the nested classpath element, further classloads from
within this class are performed by the Ant classloader which is to be
expected. What I don't understand is why the Ant classloader is not the
context classloader as well. Although I have my application server classes
in the nested classpath element, I have to set the context classloader
manually by calling

Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader(
));

before I create the InitialContext within foo.

I did not find anything about this point in the mail-archive and I'm
wondering if this is an intended behaviour. It would be nice if someone
could put some light onto this.

Thanks in advance,

Daniel




<<<<<<<<<<<<<<<<<<<<<<<<<<<
<sitewaerts> GmbH
Hebelstraße 15
D-76131 Karlsruhe

Tel: +49 (721) 920 918 0
Fax: +49 (721) 920 918 29
http://www.sitewaerts.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>

RE: Ant Classloader - Context Classloader

[cm...@yahoo.com]

On Mon, 23 Jul 2001, Conor MacNeill wrote:

> Daniel,
>
> > -----Original Message-----
> > What I don't understand is why the Ant classloader is not the
> > context classloader as well.
>
> Context classloaders are not part of JDK 1.1 so I had not set it until
> recently. In a recent change, I have set the context classloader for <java>
> tasks by reflection. I haven't however, extended that to taskdefs. Hmmm, we
> could do that just prior to execute, I guess, assuming the context loader is
> not required for task configuration.

I think it's important to _use_ the context classloader, not only to set
it ( i.e. in all Class.forName or similar ).

Assuming ant is run inside a webapp or similar environment ( where user
code is loaded in a separate classloader ), there are few cases where the
current code will not work.

Please take a look at org.apache.tomcat.util.compat, it's ( IMHO ) a
cleaner solution to the problem, with no reflection involved ( so a bit
faster ). We use the package extensively in all places where JDK1.2
features are needed ( tc3.x is also 1.1 compatible ).

Sine I run into this problem quite a few times ( with ant in classpath,
and tasks in the webapp ), I would be happy to backport it, if you want.


Costin

RE: Ant Classloader - Context Classloader

[Conor MacNeill <co...@cortexebusiness.com.au>]

Daniel,

> -----Original Message-----
> What I don't understand is why the Ant classloader is not the
> context classloader as well.

Context classloaders are not part of JDK 1.1 so I had not set it until
recently. In a recent change, I have set the context classloader for <java>
tasks by reflection. I haven't however, extended that to taskdefs. Hmmm, we
could do that just prior to execute, I guess, assuming the context loader is
not required for task configuration.

> Although I have my application server classes
> in the nested classpath element, I have to set the context classloader
> manually by calling
>
> Thread.currentThread().setContextClassLoader(this.getClass().getCl
> assLoader(
> ));
>
> before I create the InitialContext within foo.
>
> I did not find anything about this point in the mail-archive and I'm
> wondering if this is an intended behaviour. It would be nice if someone
> could put some light onto this.

There was a bug report about this, in relation to <java> tasks.