ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: Classloader question
Date Tue, 09 Oct 2001 01:05:09 GMT
On 10/8/01 8:14 AM, "Conor MacNeill" <> wrote:

> 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 only replying to ant-dev.  I should be subscribed now.

>> 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 :-(

I suspected.

>> 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 don't think so.  The problem that we are facing is actually something that
only comes up with Gump, where Sam takes the freshly built velocity jar, and
put it's onto his classpath, then invokes ant with our testbed.  That's when
we can't get to what we want.

Otherwise, it works like a charm.

Now, I think that what Gump does is something that user could do, so we want
to fix it.

> 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.

This doesn't really have anything to do with Velocity proper, but something
called 'Texen', a text generator that uses Velocity that we include in the
jar.  It isn't core to the template engine.

I know exactly where the problem is, it's in the Texen ant task, and can
change it to anything that we need to.

>> 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 :-)

Right now I don't care, as long as it works.  We can modify how the
resources are accessed from within the task - the intent of the Texen crew
is to make it easy for users by adding things to the classpath...

I will try to dumb things down with an example to remove the velocity
component, as it has nothing to do with velocity per se.


Geir Magnusson Jr.
System and Software Consulting
"They that can give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety." - Benjamin Franklin

View raw message