Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Date: 1 Feb 2004 19:36:00 -0000
Message-ID: <20040201193600.8902.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: dev@ant.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 26570]  -
    duplicate instances of  interface com.sun.javadoc.RootDoc loaded

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26570>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26570

duplicate instances of  interface com.sun.javadoc.RootDoc loaded


------- Additional Comments From eric@sandservices.com  2004-02-01 19:35 -------
This has been extraordinarily difficult to track down, and the only way I
know to reproduce it is through all the steps I actually took.  I'm not
sure what of this is critical to the process and what isn't.  Within a
single ant build:
  - javac Foo.java containing public class Foo that has a method
        public static boolean start(com.sun.javadoc.RootDoc root)
  - jar Foo.class into FooStuff.jar
  - call MyCustomTask (a custom Ant task built previously and available
    from the environment CLASSPATH) passing it the full classname of Foo 
    and the location of FooStuff.jar.  MyCustomTask then
    - creates a URLClassLoader with the URL of FooStuff.jar
    - loads class Foo
    - finds the start method via reflection
    - notes that the method has one parameter, which is a 
      com.sun.javadoc.RootDoc interface with hashCode 23894119
    - notes that Class.forName("com.sun.javadoc.RootDoc") returns a
      com.sun.javadoc.RootDoc interface with hashCode 9030750
So there are two separate instances of RootDoc at that point.

This is a problem because if I'm trying to find the start method via
reflection, the start method can't be found.  It's using the second hash to
try and find the method, so it doesn't see the method signature as == and
hence doesn't find it.

My environment CLASSPATH has c:\apache-ant-1.6.0\lib\ant.jar; and
MyCustomTasks.jar in it.  It doesn't have tools.jar.

Good point on getting ClassLoader info.  I should have tried that.  Here's
what that yielded (getClassLoader call for each RootDoc instance, and then
walk upwards from each via getParent):

"param" RootDoc CL: java.net.URLClassLoader@18a49e0
parent of "param" RootDoc CL: sun.misc.Launcher$AppClassLoader@e80a59
parent of parent of "param" RootDoc CL: 
sun.misc.Launcher$ExtClassLoader@1ff5ea7
parent of parent of parent of "param" RootDoc CL: null

"forName" RootDoc CL: java.net.URLClassLoader@affc70
parent of "forName" RootDoc CL: sun.misc.Launcher$AppClassLoader@e80a59
parent of parent of "forName" RootDoc CL: 
sun.misc.Launcher$ExtClassLoader@1ff5ea7
parent of parent of parent of "forName" RootDoc CL: null

So apparently there are two ClassLoaders off the main launcher.  Each
apparently has its own instance of RootDoc.  That doesn't sound like a good
state for things to be in given that this is such a common class, but I
don't know what the rules are for setting up ClassLoader instances or how
that's generally supposed to work.

With Ant 1.5.4, RootDoc was found in the main launcher, so apparently there
was only one instance of RootDoc loaded.  That explains why 1.5.4 works and
1.6.0 doesn't.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org