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
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.......
I will get back to you with my findings later today..
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"
boolean cidResult =
CIDResult result = new CIDResult(cidResult);
System.out.println("Executing: Retrieve CID Presentation
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:
Sent from the drools - user mailing list archive at Nabble.com