[rules-users] NoClassDefFoundError: BaseObjectClassFieldReader

Michal Bali michalbali at gmail.com
Fri Dec 5 18:07:30 EST 2008 

Oops, it was already mentioned, Sorry ..

On Fri, Dec 5, 2008 at 11:01 PM, Michal Bali <michalbali at gmail.com> 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 <fgdutton at gmail.com> 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 at post.com> 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 at gmail.com>
>> >>
>> >> 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 at post.com>
>> 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 at discover.com>
>> >> >>
>> >> >> 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
>> >> >> rules-users at 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 at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >> >
>> >> >
>> >> _______________________________________________
>> >> rules-users mailing list
>> >> rules-users at 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 at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>> >
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20081205/34e8e221/attachment.html

More information about the rules-users mailing list