[jboss-jira] [JBoss JIRA] Commented: (JBRULES-1229) separate compile classpath from class loader's getResource() facility

Godmar Back (JIRA) jira-events at lists.jboss.org
Wed Feb 20 19:12:44 EST 2008


    [ http://jira.jboss.com/jira/browse/JBRULES-1229?page=comments#action_12400121 ] 
            
Godmar Back commented on JBRULES-1229:
--------------------------------------

See http://blog.athico.com/2006/12/dynamically-generated-class-beans-as.html for some of the consequences the current design entails when it comes to the runtime generation of beans.

> separate compile classpath from class loader's getResource() facility
> ---------------------------------------------------------------------
>
>                 Key: JBRULES-1229
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1229
>             Project: JBoss Drools
>          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

        



More information about the jboss-jira mailing list