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