ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 53571] New: ClassLoader problems with Subclass of JUnitTask
Date Thu, 19 Jul 2012 19:40:38 GMT

          Priority: P2
            Bug ID: 53571
           Summary: ClassLoader problems with Subclass of JUnitTask
          Severity: normal
    Classification: Unclassified
                OS: All
          Hardware: All
            Status: NEW
           Version: 1.8.4
         Component: Optional Tasks
           Product: Ant

So I've run into a problem with my custom ant task that extends JUnitTask.
Because my subclass is loaded out of my custom jar and my custom jar also
requires the junit.jar on the tasked classpath I've run into an inconsistency
in how the JUnitTask determines if it needs to use a split classloader.

Here is the exception I run into:

/examples/build.xml:38: The <classpath> for <junit> must include junit.jar if
not in Ant's own classpath

The <junit> classpath _does_ have the junit.jar, but it's not on Ant's own
classpath. This error is caused my an inconsistency between which classloader
is being used to check the junit classes.

Here is the code in question from JUnitTask - in setupJUnitDelegate it uses the
JUnitTask.class.getClassloader (which will be loaded in the default ant
classloader which does not have junit.jar on it's classpath). It then uses
splitJunit to determine if it needs to use the split classpath, but in my case
splitJunit is false when it should be true. Since it's false it uses the
JUnitTask.class.getClassLoader() to try and load the junit classes which fails.

    protected void setupJUnitDelegate() {
        ClassLoader myLoader = JUnitTask.class.getClassLoader();
        if (splitJunit) {

The reason splitJunit is false is because it's using a different classloader to
do it's initial check. Here it's set to the result of !addClasspathResource():

    public void init() {
        antRuntimeClasses = new Path(getProject());
        splitJunit = !addClasspathResource("/junit/framework/TestCase.class");
        } else {
            mirrorLoader = myLoader;

And addClasspathResource uses getClass().getClassLoader() which in my case is
my subclass whose <taskdef> classpath _does_ have the junit.jar classes on it's
classpath (my subclass requires it to load).

    private boolean addClasspathResource(String resource) {
        File f = LoaderUtils.getResourceSource(getClass().getClassLoader(),

Changing addClasspathResource to use JUnitTask.class.getClassLoader() seems to
solve the problem, but the fact that it's not consistent is probably all that's

You are receiving this mail because:
You are the assignee for the bug.
View raw message