Since my last post was so nicely hijacked I have started a new thread in the hopes that the Drools team can shed some light on this. My setup is as follows: 1) 2 plug-ins, one containing the drools libraries, and a second plugin containing the facts and the rule file. 2) The rules engine plugin has a buddy-policy of "registered" and the facts plugin has the rules engine plugin as a registered buddy. Here is the rule(although any fact that has field assignments fails) 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. I am a little concerned when I see what appears to be a custom classloader since if you are going to embed the rules engine it should respect the classloader hierachy from the container, whether that be an app server like Websphere or client side container like Eclipse. I am wondering if the team has had success with this particular setup (the examples for Drools work cause they are all in the same plugin). I have made the example as simple as possible but still no luck. Seems like this is pretty basic functionality so I can't imagine this hasn't been tested. -- View this message in context: http://www.nabble.com/Embedding-Drools-in-Eclipse-tp20814423p20814423.html 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, Thanks for your response. I will try your suggestions as well try (again) to upgrade to M3. Having said that I am somewhat opposed to frameworks that require "special" setup and require the users to specify classloaders. To me if I understand what the container is doing with respect to classloading/classloaders than that should be enough. I shouldn't be doing anything in code to circumvent that or alter the behavior of the container. So just a little more detail on my particular use case: I have created a plug-in that contains all the Drools libraries. This is the rules engine plug-in. Developers will be creating rules and rule flows and those will be contained obviously in their own plug-ins. They may be developing new java beans or be using existing java beans from our middle-tier services. So the facts inserted into working memory could come from any plugin(any number of different classloaders in essence). Each plug-in has its own classloader. Obviously the rules engine as an IOC container needs to be able to find these classes but it doesn't make sense to always be updating the classpath of the rules framework with explicit dependencies on application components. So in order for the rules engine plug-in to be able locate these fact classes you specify in its manifest to search any of its registered buddies (Eclipse-BuddyPolicy: registered). Now the application components containing the flows/rules/fact classes will add a stanza to it its manifest registering as a buddy to the rules engine (Eclipse-RegisterBuddy: <the rules engine plug-in id>). So the rules engine manifest never has to change as new plugins are delivered to the runtime, as long as they are registered as buddies the rules engine should be able to find the rules/fact classes,etc. I think as an embedded rules engine you will see more people delivering rich clients using Eclipse as a runtime platform with drools as just another plug-in. Furthermore Eclipse is based on OSGI bundles and its classloading mechanisms, and some app servers are now moving towards OSGI (Websphere 7 I believe will have some support) Here is a great article on Eclipse classloading....... http://www.eclipsezone.com/articles/eclipse-vms/ http://www.eclipsezone.com/articles/eclipse-vms/ I will get back to you with my findings later today.. Thanks! keithnielsen wrote: > > Since my last post was so nicely hijacked I have started a new thread in > the hopes that the Drools team can shed some light on this. > > My setup is as follows: > > 1) 2 plug-ins, one containing the drools libraries, and a second plugin > containing the facts and the rule file. > 2) The rules engine plugin has a buddy-policy of "registered" and the > facts plugin has the rules engine plugin as a registered buddy. > > > Here is the rule(although any fact that has field assignments fails) > > 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. I am a little concerned when I see what > appears to be a custom classloader since if you are going to embed the > rules engine it should respect the classloader hierachy from the > container, whether that be an app server like Websphere or client side > container like Eclipse. > > I am wondering if the team has had success with this particular setup (the > examples for Drools work cause they are all in the same plugin). I have > made the example as simple as possible but still no luck. Seems like this > is pretty basic functionality so I can't imagine this hasn't been tested. > -- View this message in context: http://www.nabble.com/Embedding-Drools-in-Eclipse-tp20814423p20817058.html 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