Message
From: Steve Loughran [mailto:stevel (AT) apache (DOT) org]
Sent: Friday, 1 September 2006 8:32 PM
To: Ant Users List
Subject: Re: Jar Locking
Stephen McConnell wrote:

>Message
>From: Marc Farrow [mailto:marc.farrow (AT) gmail (DOT) com]
>Sent: Friday, 1 September 2006 2:35 AM
>To: Ant Users List
>Subject: Re: Jar Locking
>>
>Thanks Stephen. If I set all references to Ant to null and forced
>GC, would that resolve the problem?
Well, umm, this is tricky. If your loading a task or data type
definition I think Ant holds a strong reference to the class which
would suggest that setting things to null would not change (because
strong references are held for the life of the JVM). I may
be wrong
here because it's been a while since I dug into Ant
internals on task
class references - but one of the Ant Developers could
probably confirm things.
However, if your running Ant as an embedded solution - then in
principal the disposal of the Ant project would clear any task and
datatype references and you may have a chance. But this is tricky
stuff and getting it right really requires that the Ant project and
all Ant related stuff is loaded in a child classloader
relative to the
launching application (i.e. it's the classloader disposal
that is key to the releasing of the file reference).
It is possible - but it's not trivial.
Cheers, Steve.
Isnt it the case that if you hold any class created by a
classloader, there is reference to the classloader? because I
can always go object.getClass().getClassloader()
Correct.
you'd need to forget about every object created and returned
by ant itself
Yep. Which is when a plugin management framework comes in real handy.
/Steve.
Stephen McConnell
mailto:mcconnell (AT) dpml (DOT) net
http://www.dpml.net
To unsubscribe, e-mail: user-unsubscribe (AT) ant (DOT) apache.org
For additional commands, e-mail: user-help (AT) ant (DOT) apache.org