Ken, this should not happen. :-(
i'm using the task and it's predecessors since years and can not remember of such an error, but the current version is heavily refactored. I'm very interested to analyse this behaviour and fix it. Naturally I will notice you when i've found the reason. could you give some more info to reproduce this error - Ant-version !!! - Java-version - <Taskdef> of the classloader task - <classloader> - arguments (also arguments of referenced types and values/locations of properties if used) Cheers (and thx in advance too) Rainer > -----Original Message----- > From: Hoying, Ken [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 22, 2005 9:21 PM > To: Ant Users List; [EMAIL PROTECTED] > Subject: RE: Class loader problem > > > I have been playing around with the <classloader> task but > have not had much luck. > > I keep getting the following error: > > java.lang.VerifyError: (class: > org/apache/tools/ant/types/URLPath, method: > dieOnCircularReference signature: > (Ljava/util/Stack;Lorg/apache/tools/ant/Project;)V) Bad > access to protected data > > Any ideas? > > Thanks in advvance! > Ken > > -----Original Message----- > From: Rainer Noack [mailto:[EMAIL PROTECTED] > Sent: Friday, September 16, 2005 3:29 PM > To: 'Ant Users List' > Subject: RE: Class loader problem > > > Hi Ken, > If you use <taskdef/> with a classpath, the task will be loaded by a > newly created classloader that uses the project classloader > as delegation classloader. (if you're using the distributed > launch scripts, the project classloader is a delegation child > of the System classloader). > The distributed task - as well as the common Ant classes - > are loaded by the project classloader. If the delegation > child for your (older) task looks for the task's class, it > finds the newer version (with the same classname) in it's > delegation parent which takes > precedence over the class in the delegation child. > > I don't have a "clean" out-of-the-box solution for your > problem but you have some options to play with. > Their success depends mostly on your task dependencies. In > every case, you should make sure that the jar with the old > version of your task don't affect other tasks. > > 1. try the - highly deprecated and not longer documented - taskdef > attribute: reverseLoader="true" > > 2. inject your jar in project classloader's classpath prior > to the jars in $ANT_HOME/lib > by setting CLASSPATH=my_older_jar env variable > (maybe putting into $USER_HOME/.ant/lib or using the -lib > option might have the same effect but i'm not sure) > > 3. define your (old) build jar as a system extension via > ANT_OPTS="-Djava.ext.dirs=path_to_dir" > > To get more information about the classloader stuff in your > build, you might want to test <classloaderreport> which is > available under http://jtools.org/ant-classloadertask/ > (It is proposed as a CoreTask in Ant 1.7.) > > There you will also find <classloader> that allows you one more dirty > solution: > > 4. add your jar to the system-classloader's classpath via the > <classloader> task. > > Hope that helps a little bit > Cheers > Rainer > > > -----Original Message----- > > From: Hoying, Ken [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 16, 2005 5:53 PM > > To: user@ant.apache.org > > Subject: Class loader problem > > > > > > > > I am having a class loading problem with Ant. We have a > > standard Ant distribution which includes a jar file with a > > v1.1 of a task in the Ant distribution's lib directory. > > However, our project is still using the 1.0 version of this > > task. I have included the jar with the 1.0 version of the > > task in my build lib and have set a path to that build lib. > > I have referenced that path in classpathref attribute of the > > taskdef. However, no matter what I seem to do, Ant always > > seems to load the taskdef from the Ant lib jar instead of > > from the build lib jar. > > > > Any help would be greatly appreciated. > > > > Thank you, > > Ken Hoying > > > > > > > > > > ************************************************************** > > This message, including any attachments, contains > > confidential information intended for a specific individual > > and purpose, and is protected by law. If you are not the > > intended recipient, please contact sender immediately by > > reply e-mail and destroy all copies. You are hereby notified > > that any disclosure, copying, or distribution of this > > message, or the taking of any action based on it, is strictly > > prohibited. TIAA-CREF > > ************************************************************** > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > ************************************************************** > This message, including any attachments, contains > confidential information intended for a specific individual > and purpose, and is protected by law. If you are not the > intended recipient, please contact sender immediately by > reply e-mail and destroy all copies. You are hereby notified > that any disclosure, copying, or distribution of this > message, or the taking of any action based on it, is strictly > prohibited. TIAA-CREF > ************************************************************** > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
