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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]