Return-Path: Mailing-List: contact user-help@ant.apache.org; run by ezmlm Delivered-To: mailing list user@ant.apache.org Received: (qmail 45826 invoked from network); 6 Mar 2003 14:53:53 -0000 Received: from poster.ptc.com (HELO mxrelay.ptc.com) (12.11.148.30) by daedalus.apache.org with SMTP; 6 Mar 2003 14:53:53 -0000 Received: from HQ-EXFE3.ptcnet.ptc.com (localhost [127.0.0.1]) by mxrelay.ptc.com (8.9.0/8.9.0) with ESMTP id JAA23854 for ; Thu, 6 Mar 2003 09:53:54 -0500 (EST) Received: from hq-mail1.ptcnet.ptc.com ([132.253.201.69]) by HQ-EXFE3.ptcnet.ptc.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Mar 2003 09:53:54 -0500 Received: from ptc.com ([132.253.96.61]) by hq-mail1.ptcnet.ptc.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 6 Mar 2003 09:53:53 -0500 Message-ID: <3E676101.4010103@ptc.com> Date: Thu, 06 Mar 2003 09:53:53 -0500 From: Erik Price User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ant Users List Subject: Re: [OT] Re: unit test failure w/junit task References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2003 14:53:53.0793 (UTC) FILETIME=[34D69710:01C2E3F0] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Keith Hatton wrote: > Hi Erik, > > Unfortunately, I've deleted the beginning of this thread. But I seem to remember that it might have something to do with classloaders. > > Normally, you (i.e. in this case, your 3rd party lib) would load native code in a static {} block so that it only happens once during the lifetime of the VM. > > However, if different classloaders come into play, the same class can be loaded multiple times, so the static {} block gets executed multiple times. I'm getting out of my depth at this point but I presume native code is unaware of the JVM classloader separation and that's where things are going awry. > > I would have expected that would solve any issues though. Suggest you check your classpath thoroughly. My best guess is that somehow two classloaders are being asked to load the class that loads the DLL. This might actually be to do with JUnit rather than Ant as it monkeys around with the classloaders too - can you run your JUnit class through the JUnit GUI/command line interface, outside of Ant, to see what happens? I tried just about every combination of the following factors: - using fork="true" in my task - not using fork="true" in my task - putting remote connection step in setUp() in one TestCase class, storing the connection as a member of the instance - putting remote connection step in non-static initializer in one TestCase class, storing the connection as a member of the instance - putting remote connection step in non-static initializer in two TestCase classes - Then all of the above with three TestCase classes making the remote connection. And it turns out that if I'm using the remote connection in more than one TestCase class, I need to fork the process. That seems to work. (With only one TestCase class it seems that it was okay not to fork the tests. Which makes me ask, since I didn't see the answer in the docs or the book: does this fork each test into its own JVM, or just a single separate JVM from Ant itself?) Nonetheless, I will keep a watchful eye on unit tests I write that use the 3rd party library. Thanks to everyone who helped out on this thread (and the JDw/A book for both the unit test w/ant tutorial and pointing out that forking a process generally requires including the java.class.path property into the classpath for the forked process). Erik