ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: Classloader question
Date Mon, 08 Oct 2001 12:14:06 GMT
Geir Magnusson Jr. wrote:

> Howdy,

Geir, I'm moving this over to ant-dev because it touches on some pretty 
complicated issues which affect Ant's core and potentially is 
interesting for Ant2.

> I am trying to get rid of the issues that popped up recently with Ant 1.4
> and Velocity.  I will phrase the question generally...
> How do I, in a custom Ant task, dependably access the 'task classloader'?

You can't :-(

This fact really comes from the way classloaders are supposed to work. 
When we create a task classloader, it is a child of the system 
classloader. The proper "protocol" is for the child classloader to 
delegate to its parent all class loading requests. Only requests which 
cannot be satisfied are then handled by the child classloader.

Any classes which have been loaded by the parent classloader and which 
then perform other classloading operations will only be able to "see" 
the classes available to the parent classloader. The child classloader, 
even though it was the original loader invoked is no longer involved. 
This means that "factory" style objects which exist in the parent 
classloader's set of available classes are not able to function as you 
would wish.

In Ant 1.3, the classloader did not properly follow this "protocol". Ths 
lets the classloader work the way you would like, but is subject to 
problems. Basically the same class can end up being loaded into two 
different classloaders. Now that in itself is OK, but only if the 
classes in the two classloaders are isolated, i.e. they do not setup 
loader constraints. At this point you may want to read this paper, 
although it isn't light reading 
( I have 
found the resulting LinkageErrors far more difficult to handle than the 
ClassNotFound exceptions.

> But that doesn't fly in 1.4 as it appears that 1.4 delegates upwards for
> classloading (rather than downwards...)  I may have the interpretation of
> the cause  wrong - the symptom is that if you put the jar with Texen (the
> velocity.jar) in the classpath before invoking ant, you get the problem.  If
> you don't, all is fine.

Yes, this is because there is a factory at work somewhere in the 
Velocity jar.

I believe all this is one of the reasons for the introduction of the 
context classloader. Currently Ant does not set the context classloader 
for tasks, although it does set it for executing java tasks. I'm not 
sure if your classes in Velocity.jar use the context classloader but we 
can, and probably should anyway, look at setting the context loader when 
a task is executed. It needs some further thought.

> So what I want to do is ensure I always get the 'lower' classloader (or find
> another solution.)

One solution *may* be to split up the task a little and introduce a 
helper class. The task definition itself would take a classpath 
parameter and then invoke the helper class as a Java task passing a 
commandline. Potentially this may not require the helper class to be run 
in a separate VM, since the Java task is reasonably careful to isolate 
the loaded classes. The downside being that the interface between the 
task and the helper class is not type-rich. Your mileage may vary :-)


View raw message