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

[Mark Proctor]

Godmar Back 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
>   
Um I think I know how classloaders work, Drools does some pretty complex 
class loader behaviour.
> 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 user can also provide the bytecode to the classloader.
> 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.)
>   
No the compiler simply needs to have the dependant class available in 
the current or parent classloader, it does not need the bytecode. The 
class can be dynamically added to the parent classloader, at runtime, 
before you start the compilation.
> 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/c85143ea/attachment.html