I may have answered my own question. I think that it is my task that needs to set the AntClassloader as the current thread context classloader, not the taskdef as I previously thought. For some reason I though that the classpath used by the taskdef would carry over to the task, but I guess that is not the case (and that makes sense now :) ).

Thanks,

--Maciej




Maciej Zawadzki wrote:
Hello,

I am encountering a problem in the following scenario:

I am using <taskdef> with a classpathref and lets say that the classpathref pointed to by my taskdef contains the jar file MyJar.jar, which contains MyTask.class and MyBaseClass.class as well as some other classes (including a classloader). Now, when my task runs, it uses its own classloader to load class MySubClass.class (which extends MyBaseClass) from some other location. But, to load MySubClass.class, my class loader needs to obtain a reference to MyBaseClass, which would normally be no problem since it could get that probably from the parent class loader. But, when using Ant, I get a NoClassFoundError stating that MyBaseClass is not found -- even though my class loader uses the current thread context class loader as its parent.

Now, it appears to me that the classloader that is used to load MyJar.jar containing MyTask and MyBaseClass never sets itself as the current thread context classloader and that is why my class loader can not find any of those classes. Am I right in this?

After looking at the AntClassLoader and doing a search on all of Ant's code base, I found that there is only one place where the AntClassLoader is being set as the current thread context classloader -- and that is in the JUnit task. I'm not familiar enough with how the taskdef works within Ant to feel comfortable with making code changes. Thus, any help here would be greatly appreciated.

Thanks,

--Maciej


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to