<br> I don't think that what we do in drools *core* is wrong because drools core itself is not tied to OSGi or any other framework. Maybe the issue here is that we need an OSGi integration layer? something that will assemble a composite classloader from the "buddy" policies? And of course, leverage that into the drools-eclipse plugin so that it will also meet your plugin dependency requirements...<br>
<br> Faron, if you can contribute your code back, we could make it a drools-osgi module?<br><br> []s<br> Edson<br> <br><br><div class="gmail_quote">2008/12/5 keithnielsen <span dir="ltr"><<a href="mailto:keithnielsen@discover.com">keithnielsen@discover.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Faron,<br>
<br>
Thanks for your reply. I am looking at a combination of using the Eclipse<br>
buddy loading (dependent vs registered) and use of fragments (attached to<br>
the rules plug-in). However this is an eclipse implementation and I don't<br>
know all the gory details of the OSGI implementation outside that each<br>
bundle has its own classloader to know how I would accomplish the same thing<br>
with "pure" OSGI (i.e. no Eclipse buddies). So bottom line whatever solution<br>
I come up with for eclipse runtime might not translate nicely to an app<br>
server leveraging OSGI. Your solution is probably more portable to OSGI but<br>
I am fundamentally opposed to having to deal with classloaders at this<br>
level, the framework should take care of it.<br>
<br>
Edson, in answer to your question about Drools knowing about facts, "buddy"<br>
policies is the answer, you don't want the framework to change in anyway<br>
with the introduction of new facts/flows so you add your fact bundles as<br>
dependents of drools and set a property in the manifest of the drools<br>
plug-in to look at any plug-ins that declare drools plug-in as a dependent<br>
for iany facts required.<br>
<br>
I have worked through numerous issues and will document them, but I think<br>
the Drools implementation needs a second look since its forcing dependencies<br>
where their shouldn't be dependencies(vague I know, so I will back it up<br>
with some documentation once I have a fully functioning solution).<br>
<br>
Thanks<br>
<div><div></div><div class="Wj3C7c"><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>
> 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 Presentation Model");<br>
> end<br>
><br>
> Deep in the bowels of drools there is a call to<br>
> ClassFieldAccessorFactory.getClassFieldReader where it attempts to create<br>
> a class using the byte array classloader, i.e. final Class<?> newClass =<br>
> byteArrayClassLoader.defineClass(className, bytes,PROTECTION_DOMAIN). Its<br>
> at this point that a NoClassDefFoundError on the<br>
> BaseObjectClassFieldReader. From what I understand of 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 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 how<br>
> simple the object is, the minute I try to use field assignment it throws<br>
> an error.<br>
><br>
> The rules engine is running as an Eclipse plug-in.<br>
><br>
<br>
--<br>
</div></div>View this message in context: <a href="http://www.nabble.com/NoClassDefFoundError%3A-BaseObjectClassFieldReader-tp20802217p20864456.html" target="_blank">http://www.nabble.com/NoClassDefFoundError%3A-BaseObjectClassFieldReader-tp20802217p20864456.html</a><br>
<div><div></div><div class="Wj3C7c">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">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><br clear="all"><br>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br> JBoss, a division of Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a><br>