<br> 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.<br>
<br> []s<br> Edson<br><br><div><span class="gmail_quote">2007/9/25, Godmar Back <<a href="mailto:godmar@gmail.com">godmar@gmail.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My question is how to manage a rule base that is composed from sets of<br>rules drawn from different sources.<br><br>Our goal is to supply sets of rules as .jar files - each .jar file<br>containing a related set of rules. For instance, consider an expert
<br>system where different experts could export their expertise in such a<br>jar file. Such a .jar file would contain one or more .drl files and a<br>set of supporting .java classes. We'd like to be able to refer to<br>
these .jar files using a URLClassLoader and/or JarURLConnection so<br>they can be referred to without a user having to download them prior<br>to starting their application.<br><br>Users should be able to combine those provided rules (that is, the
<br>rules of those experts whose knowledge they wish to exploit) with<br>their own rules in their own .drl files.<br><br>My question is whether drools supports such a setup easily.<br>Specifically, is there a way for a user to import external .jar files
<br>in their .drl files? A statement such as<br>use jar:<a href="http://expertbase.com/expert1/knowledge5.jar">http://expertbase.com/expert1/knowledge5.jar</a><br>which would instruct the rule compiler to load the classes from this
<br>jar to its compile class path, and which would instruct the class<br>loader used to load the user's classes to delegate to the loader used<br>to load the jar file's classes? [Note that a given expert's knowledge
<br>should only be loaded by one classloader.]<br><br>I browsed through the API and discovered that the package builder<br>configuration allows the specification of a class loader. Does this<br>mean the rule compiler will attempt to load related classes through
<br>this loader as well? If so, it would need to use reflection to examine<br>those classes (which I'd find unlikely). If not, is there a way to<br>control the rule compiler's compiler classpath?<br><br>In our current prototype, we need to load everything through the
<br>application classpath to avoid compile errors.<br><br> - Godmar<br>_______________________________________________<br>rules-users mailing list<br><a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org
</a><br><a href="https://lists.jboss.org/mailman/listinfo/rules-users">https://lists.jboss.org/mailman/listinfo/rules-users</a><br></blockquote></div><br><br clear="all"><br>-- <br> Edson Tirelli<br> Software Engineer - JBoss Rules Core Developer
<br> Office: +55 11 3529-6000<br> Mobile: +55 11 9287-5646<br> JBoss, a division of Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a>