ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 22170] New: - taskdef classpaths does not work.
Date Wed, 06 Aug 2003 11:02:12 GMT
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=22170>.
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=22170

taskdef classpaths does not work.

           Summary: taskdef classpaths does not work.
           Product: Ant
           Version: 1.5.3
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Build Process
        AssignedTo: dev@ant.apache.org
        ReportedBy: tommy@tommysvensson.net


I was running version 1.5 when I found this problem. I then got version 1.5.3 to
se if the problem still existed, and it did!

The problem is that when executing an external task defined by a taskdef it
fails with a ClassNotFoundException on a class that is part of the classpath
specified in the taskdef. The funny thing is that most of the code it executes
up to the exception resides in the same classpath as the class it does not find.
The class does exists and is compiled. 

The next interesting thing is that if I setup exactly the same classpath in a
shell before running ant it works fine!! 

My taskdef has the following structure:
<taskdef ...>
  <classpath>
    <pathelement .../>
    ...
    <pathelement .../>
  </classpath>
</taskdef>

I tried the reverseLoader="true" without success. Not that I really understand
what that argument is supposed to do. 

I also tried to arrange the taskdef classpath in exactly the same order as I had
it in the shell where it worked. This didn't help either. I have double checked,
tripple checked, quadripple checked the classpath in the taskdef. It is 100%
correct, no misspelling, typos, etc.All jar files exists in the place
referenced.  And as I said above, it does find and runs other classes in the
same classpath as the class it does not find exists in. 

I can also add that the specific classpath that it fails to find the class in is
not a jar file, but a path on disk, the applications source tree. The class it
fails to find is an interface. The task uses this interface with the
java.lang.reflect.Proxy class if that could cause some conflict with the
AntClassLoader ? The problem first occured after the task started using the
Proxy class. 

Here is a stacktrace:
Caused by: java.lang.ClassNotFoundException: Path
        at java.net.URLClassLoader$1.run(URLClassLoader.java:199)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:187)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:289)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:267)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
        at
org.apache.tools.ant.AntClassLoader.findBaseClass(AntClassLoader.java:1104)
        at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:938)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:235)
        at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:302)
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:141)
        at xobint.XMLObjectProxy.childElementGetter(XMLObjectProxy.java:226)
        at xobint.XMLObjectProxy.getter(XMLObjectProxy.java:174)
        at xobint.XMLObjectProxy.invoke(XMLObjectProxy.java:126)
The XMLObjectProxy class is the one using the java.lang.reflect.Proxy class.
Then again, the Proxy class is not part of the stacktrace chain! But there is a
Class.forName() which is where the class is requsted. Requesting interfaces with
 Class.forName() is also new since the problem started. 

I can also point out that xobint.XMLObjectProxy which calls the Class.forName()
resides in a jar file and the Path class it tries to find resides in another
classpath (the application source tree). Both are specified as classpaths in the
taskdef. The Path interface is the first interface loaded with Class.forName(),
so there is none of these cases that actually do work.

Could it be the AntClassLoader that fails? When the classpath is setup in the
shell before running ant the classes are probably already loaded by the system
classloader and the AntClassLoader is not used. When Class.forName() is used to
get a class it only looks in the same classpath as the class that made the call?
I'm just speculating here!

This problem is annoying since it requires a platform dependend wrapper script
for ant that sets up the classpath before calling ant. 

/Tommy

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


Mime
View raw message