I looked at how the Drools compiler uses class loaders for the
compilation process in the case of the embedded Eclipse compiler
It appears to assume that a class's bytecode can be read as a system
resource - for instance, to allow the embedded Eclipse compiler to
find the bytecode associated with org.jboss.somepackage.SomeClass, it
will ask the classloader to open the resource
"org/jboss/somepackage/SomeClass.class". Most class loaders would in
this case return the bytecode (in ".class" file format) that they
would also use to define the class for the VM.
This means that the "import from" functionality could be implemented
via a custom URL ClassLoader which extends the list of URLs from which
it reads in response to 'from' clauses it encounters in .drl files.
This would require a slight change to the .drl grammar.
I'm not certain, though, whether others see the compelling case for
this feature. For our application, which attempts to build a system
where users can write .drl files that combine "packaged" external
rulebases+java code, this feature would allow for an extremely elegant
way of defining external dependencies. It would eliminate the need to
keep track of these dependencies in some external, out-of-band way.
On 9/26/07, Edson Tirelli <tirelli(a)post.com> wrote:
Drools does not have any special treatment/feature for classloaders.
Default java classloader hirarchy is used. So, set your URLClassLoader as
the context classloader before building the package and it shall work.
2007/9/25, Godmar Back <godmar(a)gmail.com>:
> My question is how to manage a rule base that is composed from sets of
> rules drawn from different sources.
> Our goal is to supply sets of rules as .jar files - each .jar file
> containing a related set of rules. For instance, consider an expert
> system where different experts could export their expertise in such a
> jar file. Such a .jar file would contain one or more .drl files and a
> set of supporting .java classes. We'd like to be able to refer to
> these .jar files using a URLClassLoader and/or JarURLConnection so
> they can be referred to without a user having to download them prior
> to starting their application.
> Users should be able to combine those provided rules (that is, the
> rules of those experts whose knowledge they wish to exploit) with
> their own rules in their own .drl files.
> My question is whether drools supports such a setup easily.
> Specifically, is there a way for a user to import external .jar files
> in their .drl files? A statement such as
> use jar:http://expertbase.com/expert1/knowledge5.jar
> which would instruct the rule compiler to load the classes from this
> jar to its compile class path, and which would instruct the class
> loader used to load the user's classes to delegate to the loader used
> to load the jar file's classes? [Note that a given expert's knowledge
> should only be loaded by one classloader.]
> I browsed through the API and discovered that the package builder
> configuration allows the specification of a class loader. Does this
> mean the rule compiler will attempt to load related classes through
> this loader as well? If so, it would need to use reflection to examine
> those classes (which I'd find unlikely). If not, is there a way to
> control the rule compiler's compiler classpath?
> In our current prototype, we need to load everything through the
> application classpath to avoid compile errors.
> - Godmar
> rules-users mailing list
Software Engineer - JBoss Rules Core Developer
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
rules-users mailing list