Oops, it was already mentioned, Sorry ..<br><br><div class="gmail_quote">On Fri, Dec 5, 2008 at 11:01 PM, Michal Bali <span dir="ltr"><<a href="mailto:michalbali@gmail.com">michalbali@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I vaguely remember reading about similar issues with OSGi. It was solved by using so called "buddy loading":<br>
<a href="http://help.eclipse.org/ganymede/topic/org.eclipse.platform.doc.isv/reference/misc/buddy_loading.html" target="_blank">http://help.eclipse.org/ganymede/topic/org.eclipse.platform.doc.isv/reference/misc/buddy_loading.html</a><br>
Hope it helps.<div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Fri, Dec 5, 2008 at 10:11 PM, Faron Dutton <span dir="ltr"><<a href="mailto:fgdutton@gmail.com" target="_blank">fgdutton@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Once I work out the kinks, I could provide the code (e.g.,<br>
ClassLoaders) on the wiki.<br>
<br>
Unfortunately, Drools cannot anticipate dependencies and there is no<br>
special sauce for adding them at runtime. It would be nice if Drools<br>
was more consistent in its use of ClassLoader. I know this is vague;<br>
I'll try to provide some example later. Its been about two weeks since<br>
I wrote the solution so I'll need to go back and find them again. MVEL<br>
appears to be a bigger issue though. The ClassLoader should really be<br>
associated with the working memory instead of the thread.<br>
<div><div></div><div><br>
On Fri, Dec 5, 2008 at 4:52 PM, Edson Tirelli <<a href="mailto:tirelli@post.com" target="_blank">tirelli@post.com</a>> wrote:<br>
><br>
> Thanks a lot for the information. Maybe we should add this to a Wiki<br>
> page?<br>
><br>
> From a Drools perspective, a solution like you proposed should work for<br>
> any case, since we also internally tell MVEL to use the same classloader<br>
> hierarchy... unless there is some unknown bug.<br>
><br>
> Regarding declaring dependencies, I don't understand how Drools could<br>
> declare such dependency since the fact classes are defined and provided by<br>
> users and not known by drools in advance. Is there some default mechanism<br>
> that we could implement to support such things "automagically" in OSGi<br>
> deployments?<br>
><br>
> []s<br>
> Edson<br>
><br>
> 2008/12/5 Faron Dutton <<a href="mailto:fgdutton@gmail.com" target="_blank">fgdutton@gmail.com</a>><br>
>><br>
>> I have successfully loaded rules and facts from other bundles in Eclipse<br>
>> 3.4.<br>
>><br>
>> I encountered the same issue, which is due to the ClassLoader behavior<br>
>> defined by OSGi v4. Eclipse 3.3 introduced the new behavior and<br>
>> Eclipse 3.4 aggressively adheres to the specification. Drools attempts<br>
>> to access a Class through a reference to a ClassLoader, which by<br>
>> default is its bundle ClassLoader. MVEL attempts to access a Class<br>
>> through the context ClassLoader, which OSGi sets to the bundle's<br>
>> ClassLoader. The problem arises because neither the Drools bundle nor<br>
>> the MVEL bundle (I have each Drools artifact in a separate bundle)<br>
>> declare a dependency on the package containing the fact's Class.<br>
>> Therefore, OSGi does not add that package to the bundle's ClassLoader<br>
>> and you get a ClassNotFoundException when Drools attempts to find the<br>
>> Class.<br>
>><br>
>> I worked around this issue by doing several things:<br>
>> 1) Created an implementation of ClassLoader that delegates to the<br>
>> bundle (BundleClassLoader).<br>
>> 2) Created a composite ClassLoader that contains many bundle<br>
>> ClassLoaders (CompositeClassLoader).<br>
>> 3) For each bundle containing a rule or fact, wrap it in a<br>
>> BundleClassLoader and add it to the CompositeClassLoader.<br>
>> 4) Pass the CompositeClassLoader to the methods mentioned in Edson's post.<br>
>> 5) Wrap the working memory in a Class that sets the context<br>
>> ClassLoader before each method invocation and restores the original<br>
>> context ClassLoader afterwards.<br>
>><br>
>> This takes care of most but not all of the issues. Specifically, some<br>
>> invocations of MVEL still fail but the system works. I am continuing<br>
>> to investigate a more elegant solution.<br>
>><br>
>> Faron.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Wed, Dec 3, 2008 at 10:11 AM, Edson Tirelli <<a href="mailto:tirelli@post.com" target="_blank">tirelli@post.com</a>> wrote:<br>
>> ><br>
>> > What do you mean by "facts in other plugins"?<br>
>> ><br>
>> > If your facts are loaded by a different classloader hierarchy, you<br>
>> > need<br>
>> > to set the facts classloader in:<br>
>> ><br>
>> > PackageBuilderConfiguration.setClassLoader(); // to compile the rules<br>
>> > RulebaseConfiguration.setClassLoader(); // to create the rulebase and<br>
>> > run it<br>
>> ><br>
>> > []s<br>
>> > Edson<br>
>> ><br>
>> > 2008/12/2 keithnielsen <<a href="mailto:keithnielsen@discover.com" target="_blank">keithnielsen@discover.com</a>><br>
>> >><br>
>> >> Further testing shows that while the rules engine can locate facts from<br>
>> >> other<br>
>> >> plug-ins (facts located in the same plugin as the rules engine work<br>
>> >> fine,<br>
>> >> but not realistic to expect that all facts will be co-located in the<br>
>> >> same<br>
>> >> plugin), an attempt to reconstitute them using the ByteArrayClassloader<br>
>> >> will<br>
>> >> not work. Has anyone been successful using facts located in other<br>
>> >> plug-ins?<br>
>> >> I am using Drools 5.M2 with Eclipse 3.4.<br>
>> >><br>
>> >><br>
>> >><br>
>> >> keithnielsen wrote:<br>
>> >> ><br>
>> >> > I have the following rule:<br>
>> >> ><br>
>> >> > rule "Retrieve CID Presentation Model"<br>
>> >> > ruleflow-group "RetrieveCID"<br>
>> >> ><br>
>> >> > when<br>
>> >> ><br>
>> >> ><br>
>> >> ><br>
>> >> > CIDPresentationModel($cidValue:cidValue,$cidExpirationDate:expirationDate)<br>
>> >> > then<br>
>> >> > boolean cidResult =<br>
>> >> > cidService.verifyCIDIsValid($cidValue,$cidExpirationDate);<br>
>> >> > CIDResult result = new CIDResult(cidResult);<br>
>> >> > insert(result);<br>
>> >> > System.out.println("Executing: Retrieve CID<br>
>> >> > Presentation<br>
>> >> > Model");<br>
>> >> > end<br>
>> >> ><br>
>> >> > Deep in the bowels of drools there is a call to<br>
>> >> > ClassFieldAccessorFactory.getClassFieldReader where it attempts to<br>
>> >> > create<br>
>> >> > a class using the byte array classloader, i.e. final Class<?><br>
>> >> > newClass =<br>
>> >> > byteArrayClassLoader.defineClass(className, bytes,PROTECTION_DOMAIN).<br>
>> >> > Its<br>
>> >> > at this point that a NoClassDefFoundError on the<br>
>> >> > BaseObjectClassFieldReader. From what I understand of<br>
>> >> > NoClassDefFoundError<br>
>> >> > it can result when there are two sources of the same class in the<br>
>> >> > classpath or if there is some reference from the class resulting in<br>
>> >> > the<br>
>> >> > error to another class that can not be resolved. It only appears in<br>
>> >> > situations where there is fields involved. It doesnt seem to matter<br>
>> >> > how<br>
>> >> > simple the object is, the minute I try to use field assignment it<br>
>> >> > throws<br>
>> >> > an error.<br>
>> >> ><br>
>> >> > The rules engine is running as an Eclipse plug-in.<br>
>> >> ><br>
>> >><br>
>> >> --<br>
>> >> View this message in context:<br>
>> >><br>
>> >> <a href="http://www.nabble.com/NoClassDefFoundError%3A-BaseObjectClassFieldReader-tp20802217p20806634.html" target="_blank">http://www.nabble.com/NoClassDefFoundError%3A-BaseObjectClassFieldReader-tp20802217p20806634.html</a><br>
>> >> Sent from the drools - user mailing list archive at Nabble.com.<br>
>> >><br>
>> >> _______________________________________________<br>
>> >> rules-users mailing list<br>
>> >> <a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
>> >> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > Edson Tirelli<br>
>> > JBoss Drools Core Development<br>
>> > JBoss, a division of Red Hat @ <a href="http://www.jboss.com" target="_blank">www.jboss.com</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > rules-users mailing list<br>
>> > <a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
>> > <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
>> ><br>
>> ><br>
>> _______________________________________________<br>
>> rules-users mailing list<br>
>> <a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
><br>
><br>
><br>
> --<br>
> Edson Tirelli<br>
> JBoss Drools Core Development<br>
> JBoss, a division of Red Hat @ <a href="http://www.jboss.com" target="_blank">www.jboss.com</a><br>
><br>
> _______________________________________________<br>
> rules-users mailing list<br>
> <a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
><br>
><br>
_______________________________________________<br>
rules-users mailing list<br>
<a href="mailto:rules-users@lists.jboss.org" target="_blank">rules-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>