DO NOT REPLY [Bug 30161] New: - [PATCH] Impossible to use implicit classpath for when Ant core loader != Java application loader and Path.systemClassPath taken from ${java.class.path}

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=30161>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=30161

[PATCH] Impossible to use implicit classpath for <taskdef> when Ant core loader != Java application loader and Path.systemClassPath taken from ${java.class.path}

           Summary: [PATCH] Impossible to use implicit classpath for
                    <taskdef> when Ant core loader != Java application
                    loader and Path.systemClassPath taken from
                    ${java.class.path}
           Product: Ant
           Version: 1.6.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Core
        AssignedTo: dev@ant.apache.org
        ReportedBy: jglick@netbeans.org


Background: http://www.netbeans.org/issues/show_bug.cgi?id=46171

It seems that AntClassLoader.findResources is buggy in case
AntClassLoader.parent is something other than
ClassLoader.getSystemClassLoader(). The way ClassLoader.getResources works is
that the (CL.)parent is first checked and then this.findResources is appended.
However ACL never sets CL.parent explicitly; it only used its own independent
ACL.parent field, and CL.parent is left at the default value, CL.sCL.

This means that ACL.parent.findResources is never called and so any resources
that might be contained in it are never found. This can affect e.g. <taskdef>
with no explicit classpath. (Note that ACL.getResource (find a single resource)
is correct, as far as I know.)

Specifically the problem arises when Ant is run from a container such as the
NetBeans IDE, for then the class loader which loads Ant core classes is not the
app class loader. For example, consider this script:

<project default="fail">
    <property name="antcontrib.jar"
location="/tmp/ant-contrib/lib/ant-contrib-1.0b1.jar"/>
    <target name="automatic">
        <ac:urlencode xmlns:ac="antlib:net.sf.antcontrib" name="encoded"
value="hey there"/>
        <echo>${encoded}</echo>
    </target>
    <target name="taskdef-implicit">
        <taskdef resource="net/sf/antcontrib/antlib.xml"/>
        <urlencode name="encoded" value="hey there"/>
        <echo>${encoded}</echo>
    </target>
    <target name="taskdef-explicit">
        <taskdef resource="net/sf/antcontrib/antlib.xml"
classpath="${antcontrib.jar}"/>
        <urlencode name="encoded" value="hey there"/>
        <echo>${encoded}</echo>
    </target>
</project>

If antcontrib.jar is in the $CLASSPATH or passed to Ant via -lib, all three
targets work. In the IDE, only taskdef-explicit works even if antcontrib.jar is
added to the class loader used by Ant core classes (NetBeans #46171)... unless
you patch the IDE to set Path.systemClassPath to a path containing the JARs in
that class loader. The default value of Path.sCP is taken from the system
property ${java.class.path}, which could be just about anything, related to Ant
or not. (Ant's launcher hacks around that by faking java.class.path.)

Since I know of a workaround for the IDE, I am only submitting this patch for
consideration by committers, lest other Ant integrators beat their heads against
the wall over this problem.

Note that there is a problem with the patch (which is I believe unavoidable
unless you set CL.parent correctly, or override CL.getResources in JDK 1.5 where
it seems to be nonfinal): if CL.parent (whatever that is) does have any matches
for the resource name, and ACL.parent has matches for it that are in fact
derived ultimately from CL.parent, ACL.getResources will produce duplicates. I
put in a quick hack to avoid this in case CL.parent == ACL.parent, but for a
more general fix I suppose you would have to call CL.parent.getResources and
remove all such matches before returning them from ACL.findResources. I have not
tried such a refinement yet.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org