ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Neward" <tnew...@javageeks.com>
Subject RE: Classloader question
Date Tue, 09 Oct 2001 05:46:07 GMT
> 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.
>
The context ClassLoader was introduced for *precisely* this reason; both RMI
and JNDI need to be able to "reach down" to the lowest child ClassLoader in
the delegation tree and load code from there, so it was introduced in Java2
(along with the rest of the new ClassLoader scheme).

<ad>
If you don't want to read the Liang/Bracha paper, might I humbly suggest
some of the papers on my website (www.javageeks.com/Papers) or my book
(www.manning.com/Neward3/). Bill Venners' "Inside the Java2 Virtual Machine"
also does a good job of explaining ClassLoader delegation, as well.
</ad>

Conor, how hard would it be to simply set the context classloader in the
main thread when Ant kicks off? (Threads inherit the context ClassLoader
when spun off, so once set, it would be set for any and all threads created
within Ant.) This would then make the "task classloader" easily available
for any and all to use.

Ted Neward
{.NET||Java} Course Author & Instructor
DevelopMentor (http://www.develop.com)
http://www.javageeks.com/tneward/index.html

> -----Original Message-----
> From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
> Sent: Monday, October 08, 2001 5:14 AM
> To: ant-user@jakarta.apache.org
> Cc: geirm@optonline.net; ant-dev@jakarta.apache.org
> Subject: Re: Classloader question
>
>
> 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
> (http://www.cs.purdue.edu/homes/jv/smc/pubs/liang-oopsla98.pdf). 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 :-)
>
> Conor
>
>


Mime
View raw message