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

[Mark Proctor]

What you can do is load the classes into a classloader at runtime and 
then pass that classloader to the PackageBuillderConfiguration 
RuleBaseConfiguration. Any DRLs that it then compiles will compile 
against the classes in the parent classloader. So while we don't have 
explicit support for this, you could build your own api, that wraps 
drools, to do this.

Mark
Godmar Back wrote:
> On 9/26/07, Edson Tirelli <tirelli at 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.
>>
>>     
>
> I find it unlikely that this works. The compiler probably won't load
> classes from the context classloader (after all, the classloader
> doesn't have an interface to obtain the bytecode associated with a
> name - all it provides is a method to retrieve a java.lang.Class
> object, which the compiler doesn't need. The compiler needs to examine
> the bytecode of referred classes.)
>
> Even if it did work, it would be insufficient because I do not know
> the URL until I've seen the drl file. Otherwise, I would have to keep
> that dependency information somewhere else - I'd like to keep it in
> the .drl file and let drool do the work.
>
> Let me propose the following enhancement.
> Add an optional "from" clause to the "import" statement. For instance,
> allow a user to say:
>
> import org.somefeature.somepackage from http://somefeature.org/ourpackages.jar;
>
> This would instruct the compiler to include this .jar in its compile
> class path. In addition, it would compile a list of jar URLs upon
> which the rules depend when being executed. A method on package
> builder could then be added that would retrieve that list of URLs such
> that a classloader could be created to load those classes.  Either
> "URL [] PackageBuilder.getReferencedURLs()" or possibly better
> "ClassLoader PackageBuilder.createLoader()" where a suitably
> configured subclass of URLClassLoader is returned.
>
>  - Godmar
>
>   
>> 2007/9/25, Godmar Back <godmar at 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
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>       
>>
>> --
>>   Edson Tirelli
>>   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
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>     
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>   

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