While getResource is overridden to search ACL.parent (see bug #749), getResources is not. Therefore it uses CL.getResources, which uses CL.parent, which in the case of ACL is arbitrarily initialized to CL.getSystemClassLoader(). Therefore an ACL whose ACL.parent cannot "see" some resource, and whose pathComponents does not contain it, will nonetheless return it from getResources if that resource can be found in the application classpath. This is bad because, for example, ServiceLoader calls getResources("META-INF/services/....") and tries to load all the classes it finds using the same loader. If the configured loader is an ACL (or a child of one) which is not parented to the app CP, and the app CP defines some services, then a ServiceConfigurationError will result. See: http://www.netbeans.org/nonav/issues/show_bug.cgi?id=158934
*** This bug has been marked as a duplicate of bug 46759 ***
Is this one a duplicate of the other ones? I think that this one can be fixed independently of fixing the other ant classloader issues.
since getResources in Java 1.4 is final, is there anything we can do until Ant moves to Java 5? see bug 35436 Maybe overriding findResources would help.
obviously overriding findResources doesn't help, since we already do that. Sorry.
There now is an AntClassLoader5 class which overrides getResources. This class will be used by all classes in Ant when it is available (and Ant is running on Java5, of course). The real implementation sits in AntClassLoader.getNamedResources but that probably doesn't help people in Java 1.4 land too much. svn revision 796647