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.

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 <keithnielsen(a)discover.com&gt; > > 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-... > Sent from the drools - user mailing list archive at Nabble.com. > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > 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 rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

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 <fgdutton(a)gmail.com&gt; > > 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 <tirelli(a)post.com&gt; 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 <keithnielsen(a)discover.com&gt; > >> > >> 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-... > >> Sent from the drools - user mailing list archive at Nabble.com. > >> > >> _______________________________________________ > >> rules-users mailing list > >> rules-users(a)lists.jboss.org > >> 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 > > rules-users(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > 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 rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

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/refer... Hope it helps. On Fri, Dec 5, 2008 at 10:11 PM, Faron Dutton <fgdutton(a)gmail.com&gt; 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 <tirelli(a)post.com&gt; 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 <fgdutton(a)gmail.com&gt; > >> > >> 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 <tirelli(a)post.com&gt; > 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 <keithnielsen(a)discover.com&gt; > >> >> > >> >> 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-... > >> >> Sent from the drools - user mailing list archive at Nabble.com. > >> >> > >> >> _______________________________________________ > >> >> rules-users mailing list > >> >> rules-users(a)lists.jboss.org > >> >> 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 > >> > rules-users(a)lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/rules-users > >> > > >> > > >> _______________________________________________ > >> rules-users mailing list > >> rules-users(a)lists.jboss.org > >> 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 > > rules-users(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users >

Faron, Thanks for your reply. I am looking at a combination of using the Eclipse buddy loading (dependent vs registered) and use of fragments (attached to the rules plug-in). However this is an eclipse implementation and I don't know all the gory details of the OSGI implementation outside that each bundle has its own classloader to know how I would accomplish the same thing with "pure" OSGI (i.e. no Eclipse buddies). So bottom line whatever solution I come up with for eclipse runtime might not translate nicely to an app server leveraging OSGI. Your solution is probably more portable to OSGI but I am fundamentally opposed to having to deal with classloaders at this level, the framework should take care of it. Edson, in answer to your question about Drools knowing about facts, "buddy" policies is the answer, you don't want the framework to change in anyway with the introduction of new facts/flows so you add your fact bundles as dependents of drools and set a property in the manifest of the drools plug-in to look at any plug-ins that declare drools plug-in as a dependent for iany facts required. I have worked through numerous issues and will document them, but I think the Drools implementation needs a second look since its forcing dependencies where their shouldn't be dependencies(vague I know, so I will back it up with some documentation once I have a fully functioning solution). Thanks 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-... Sent from the drools - user mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users