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. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@ant.apache.org For additional commands, e-mail: user-h...@ant.apache.org