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

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

On 9/26/07, Godmar Back <godmar(a)gmail.com&gt; wrote: > On 9/26/07, Mark Proctor <mproctor(a)codehaus.org&gt; 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 > >