ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Classloader not collected using junit4 in ant 1.8.1
Date Sun, 10 Jul 2011 16:53:08 GMT
On 2011-07-07, Markus Oley wrote:

> I have a problem which classloading and ant 1.8.1, junit 4.8.2 and
> log4j 1.2.16 or any third-party libraries:

Any chance you could try 1.8.2?  I vaguely recall we fixed something
there but can't find any evidence for it in svn.

It would also be good if you could try to figure out whether <junit> or
<antcall> is causing the problem by moving the <antcall> out of the way.

> 1. Is this behaviour of the classloaders a behaviour you would expect
> or do we have a classloader-leak?

It definitively sounds like a bug to me.

> 2. Do we have to cleanup all statics and singletons to decrease
> memory-footprint or does a generic solution exist?

In theory Ant will remove all references to the classloaders but it is
unclear to me whether log4j may be keeping hold on them.

> 3. parameter -lib is only a workaround, isn't it? How should we give
> the libs to ant?

-libs is not a workaround at all.  It is the recommended way to put
things into the system classloader for a runnign Ant instance.

> 4. Is it possible to use reloading="false"? I guess I didn't have any
> other behaviour

With reloading="false" all test run within the same <junit> task
instance should be sharing the same classloader.  In your case you have
two different <junit> tasks and thus two different classloaders anyway.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message