separate compile classpath from class loader's getResource() facility --------------------------------------------------------------------- Key: JBRULES-1229 URL: http://jira.jboss.com/jira/browse/JBRULES-1229 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.1 Reporter: Godmar Back Assigned To: Mark Proctor Priority: Minor The current compiler relies on being able to read the bytecode for referred-to classes as a resource. For instance, to resolve the name "org.jboss.pkg.Clazz", a resource "org/jboss/pkg/Clazz.class" must be accessible. This requirement is not part of the public interface of a class loader. Read the Sun Java documentation, which states: "A resource is some data (images, audio, text, etc) that can be accessed by class code in a way that is independent of the location of the code." Although, this approach works by coincidence since most class loaders in fact return this resource - at least class loaders that don't do anything fancy to bytecode before defining classes, a more principled solution would separate the classpath used by the runtime engine from the classpath used by the compiler. (This is, for instance, what javac or practically all command-line compilers do.) My suggestion is to either document this dependency on this particular class loader behavior, or, better, introduce a specific type resolver for the compilation process that is separated from the class loader's resource loading mechanism. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira