Bug 22170 - taskdef classpaths does not work.
Summary: taskdef classpaths does not work.
Status: RESOLVED DUPLICATE of bug 6606
Alias: None
Product: Ant
Classification: Unclassified
Component: Build Process (show other bugs)
Version: 1.5.3
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL: http://ant.apache.org/faq.html#delega...
Keywords:
Depends on:
Blocks:
 
Reported: 2003-08-06 11:02 UTC by Tommy Svensson
Modified: 2008-02-22 12:18 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tommy Svensson 2003-08-06 11:02:11 UTC
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
Comment 1 Stefan Bodewig 2003-08-06 11:13:31 UTC
Most likely you have part of the classes your task needs on the system classpath
and a different part is not there.



*** This bug has been marked as a duplicate of 6606 ***
Comment 2 Ralf Hauser 2005-03-29 14:10:00 UTC
perhaps a cleanly defined classpathref as per Bug 31555 helps here