[rules-users] how to specify classpath dependencies in .drl files.

[Mark Proctor]

Godmar Back wrote:
> PS: I looked at what Drools does in the Eclipse compiler configuration.
>
> It appears to assume that a class's bytecode can be found as a system
> resource, via getResourceAsStream(). See
> org.drools.common.jci.compilers.EclipseJavaCompiler.java.
>
> In other words, if the compiler asks for the byte code for Class
> org.jboss.somepackage.SomeClass, Drools will ask the class loader for
> the resource with path "org/jboss/somepackage/SomeClass.class".
> Although most class loaders would at this point return an InputStream
> from which the bytecode of this class can be read, there is no
> requirement that they do so - or that this resource exists at all. For
> instance, class loaders that rewrite bytecode on the fly would provide
> different bytecode from this system resource than otherwise.
>
> Nevertheless, it is a reasonable assumption, and it means that
> implementing the import from functionality may not be difficult. I'm
> getting the feeling though, that you have doubts about its usefulness.
>
>  - Godmar
>   
Again you are reading this wrong, I think you have a fundamental 
misunderstanding of how classloaders work in Java. See my previous 
email. Simple add the class at runtime to a classloader and use that 
classloader as the root classloader of the packagebuilder.
> On 9/26/07, Godmar Back <godmar at gmail.com> wrote:
>   
>> On 9/26/07, Mark Proctor <mproctor at codehaus.org> wrote:
>>     
>>>  Godmar Back wrote:
>>>  [off list]
>>>
>>>
>>> Like I said, I doubt that this works.
>>>
>>> Classloaders don't produce the bytecode a compiler needs. It's not
>>> part of their interface.
>>>
>>>  Don't produce what bytecode? If you are dynnamically loading classes are
>>> runtime, that .class has the bytecode. This is what people are doing now
>>> already with web services. Drools has its own runtime compiler and will
>>> compile fine against dynamically loaded classes in a parent classloader.
>>>
>>>       
>> No, that's not how class loaders work.
>> A class loader, fundamentally, implements a method
>>
>> public Class loadClass(String name) throws ClassNotFoundException
>>
>> that maps class names to class objects. For instance, the name
>> "org.jboss.pkg.SomeClass" may be mapped to an object of type
>> java.lang.Class - such as one that would be returned by defineClass().
>>
>> Although the class loader internally reads the content of .class files
>> - either from a URL, from a jar, or from disk, there is no interface
>> to obtain the actual bytecode from a class loader.
>> There is no method: "byte [] getByteCode(String name)". A class loader
>> will internally read the (bytes constituting) a .class file, then
>> passes it to "defineClass()", which is where the JVM parses the
>> bytecode and creates a java.lang.Class instance.
>>
>> A compiler that is compiling code that refers to a class needs access
>> to that class's bytecode, directly. Access to a class object as
>> provided by a ClassLoader is insufficient. (Also, it would be
>> dangerous - reflexive examination may trigger a "first active use"
>> (See JLS - 12.4.1 in 1st edition) - you don't want the compilation to
>> trigger static initializers of referred classes.)
>>
>> Given that, the drools compiler would need to have a way to load the
>> actual bytecode, something a classloader cannot provide.
>>
>> Hence my suggestion to enhance it allow a user-controlled way of
>> providing that bytecode.
>>
>>  - Godmar
>>
>>     
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070927/0a13971d/attachment.html