[rules-users] Unresolved Object Reference
Ronald R. DiFrango
ron.difrango at gmail.com
Fri Jul 6 13:08:33 EDT 2007
Thanks Edson! I really do not like the fact that XML Beans does this, I am
trying an Castor as an alternative.
On 7/6/07, Edson Tirelli <tirelli at post.com> wrote:
>
>
> Ronald,
>
> Shadow facts only role is to ensure the integrity of the working
> memory. Basically what they do is to only allow the engine to "see" the
> changes to facts at safe "update" points.
>
> Without a shadow, facts that have constrained attributes may present
> undetermined behavior... sometimes rules that should fire will not fire or
> vice-versa, usually there will be memory leaks, etc. So, to be brief, it
> will not work, even if it may appear to be working.
>
> Well, we try to make shadow facts as transparent as possible to the
> user and to the engine, because shadow facts obviously will add overhead to
> the runtime environment. If they are transparent, advanced user can "tune
> performance" by disabling shadow facts for classes that don't need them.
>
> To do that, we chose to go with a "proxy" strategy. So, we create a
> lazy loaded cache proxy for each fact asserted into the working memory. To
> do that, we need actual asserted fact classes to not be final, and also we
> are required to override equals and hashCode methods.
>
> In the future, we may try to pursue other strategies, but for now, our
> only recommendation is to not assert facts of classes that are final or have
> declared equals/hashcode methods as final.
>
> []s
> Edson
>
> 2007/7/6, Ronald R. DiFrango <ron.difrango at gmail.com>:
> >
> > Edson,
> >
> > Oh, this could be bad news then. I do have cases where I have code like
> > the following:
> >
> > detailLine: DetailLine(status != "Matched", ....other stuff....)
> >
> > then
> >
> > detailLine.setStatus ("Matched")
> >
> > What might the implications be then?
> >
> > Ron
> >
> > On 7/6/07, Edson Tirelli < tirelli at post.com > wrote:
> > >
> > >
> > > Ronald,
> > >
> > > You can't change constrained values of facts that are not
> > > shadowed.
> > > Exemple: if you have a rule that does:
> > >
> > > Person( name == "someValue" )
> > >
> > > If person is not shadowed, you can't change the name attribute
> > > while the object is in the working memory or you may get unexpected behavior
> > > from the engine. But for instance, if you don't constrain another attribute,
> > > like "age", you can change it without any problems.
> > >
> > > []s
> > > Edson
> > >
> > > 2007/7/5, Ronald R. DiFrango < ron.difrango at gmail.com>:
> > > >
> > > > Edson,
> > > >
> > > > That is indeed the case, XML Beans is generating final
> > > > equals/hashCdoe methods. I have no idea why that is case. I may post this
> > > > over on the XML Beans board.
> > > >
> > > > Is disabling the shadowing a problem from the rules execution point
> > > > of view?
> > > >
> > > > Finally, I guess I need to do a source build, can I find the
> > > > instructions somewhere on this?
> > > >
> > > > Ron
> > > >
> > > > On 7/5/07, Edson Tirelli < tirelli at post.com> wrote:
> > > > >
> > > > >
> > > > > There was a problem with CGLIB proxies much similar to this...
> > > > > so probably the same problem.
> > > > >
> > > > > What happens is that to shadow a fact, drools needs to extend
> > > > > the actual class being asserted, and override the equals and hashcode
> > > > > methods. So, the class can't be final, nor these methods can be final.
> > > > > Previously I wasn't checking for final on these methods and that was the
> > > > > reason for the error.
> > > > >
> > > > > I fixed that in trunk. It means, if XML Beans are generating
> > > > > methods equals/hashCode as final, drools won't be able to shadow them (and
> > > > > so will automatically disable shadowing for them), but it will not raise the
> > > > > error anymore.
> > > > >
> > > > > Let me know if it is still a problem for you in trunk.
> > > > >
> > > > > []s
> > > > > Edson
> > > > >
> > > > > 2007/7/5, Ronald R. DiFrango < ron.difrango at gmail.com >:
> > > > > >
> > > > > > All this sounds eerily similar to the problem I am reporting.
> > > > > > In the 4.0 version I am getting the following exception on those
> > > > > > inner classes:
> > > > > >
> > > > > > Exception in thread "main" java.lang.VerifyError: class
> > > > > > com.circuitcity.rtvcrms.impl.DetailLineDocumentImpl$DetailLineImplShadowProxyoverrides final method ã Ý*h '+ .û Ý*h '+
> > > > > > at java.lang.ClassLoader.defineClass1(Native Method)
> > > > > > at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> > > > > > at java.lang.ClassLoader.defineClass (ClassLoader.java:465)
> > > > > > at org.drools.rule.MapBackedClassLoader.fastFindClass(
> > > > > > MapBackedClassLoader.java:40)
> > > > > > at org.drools.rule.MapBackedClassLoader.loadClass(
> > > > > > MapBackedClassLoader.java:59)
> > > > > > at java.lang.ClassLoader.loadClass (ClassLoader.java:251)
> > > > > > at org.drools.reteoo.Rete$ObjectTypeConf.<init>(Rete.java
> > > > > > :352)
> > > > > > at org.drools.reteoo.Rete.assertObject(Rete.java:152)
> > > > > > at org.drools.reteoo.ReteooRuleBase.assertObject(
> > > > > > ReteooRuleBase.java :190)
> > > > > > at org.drools.reteoo.ReteooWorkingMemory.doInsert(
> > > > > > ReteooWorkingMemory.java:70)
> > > > > > at org.drools.common.AbstractWorkingMemory.insert(
> > > > > > AbstractWorkingMemory.java:772)
> > > > > > at org.drools.common.AbstractWorkingMemory.insert (
> > > > > > AbstractWorkingMemory.java:584)
> > > > > > at
> > > > > > com.circuitcity.rtvcrms.rules.RtvDecisionEngine.processDetailLines
> > > > > > (RtvDecisionEngine.java:95)
> > > > > > at
> > > > > > com.circuitcity.rtvcrms.rules.RtvDecisionEngine.executeRules(
> > > > > > RtvDecisionEngine.java :64)
> > > > > > at com.circuitcity.rtvcrms.test.MainBasedTester.main(
> > > > > > MainBasedTester.java:34)
> > > > > >
> > > > > > The catch is that XML Beans objects are auto generated based
> > > > > > upon and XSD and we have limited control over what gets generated.
> > > > > >
> > > > > > On 7/5/07, Narendra Valada < narendra.valada at gmail.com> wrote:
> > > > > > >
> > > > > > > Thank you for your quick response.
> > > > > > >
> > > > > > > I cannot make the Outer class static and public since it is
> > > > > > > not an inner class.
> > > > > > >
> > > > > > > In my example, I have two inner classes : Inner and
> > > > > > > InnerInner.
> > > > > > >
> > > > > > > Class Inner is enclosed by Outer and class InnerInner is
> > > > > > > enclosed by Inner. I get the "Unable to resolve object type" error only on
> > > > > > > the "InnerInner" class and not on the "Inner" class.
> > > > > > >
> > > > > > > Both the inner classes are defined as non-static.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Narendra
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 7/5/07, Mark Proctor <mproctor at codehaus.org > wrote:
> > > > > > > >
> > > > > > > > you need to make your Outer class static and public. Look at
> > > > > > > > the sample generated with a new drools project, that uses a static public
> > > > > > > > class.
> > > > > > > >
> > > > > > > > Mark
> > > > > > > > Narendra Valada wrote:
> > > > > > > >
> > > > > > > > * **Hello,*
> > > > > > > > * *
> > > > > > > > *I am getting an "Unable to resolve object type" error on
> > > > > > > > certain XML Bean generated inner classes. I get this error only on inner
> > > > > > > > classes that have been defined within other inner classes. Please see
> > > > > > > > example below. *
> > > > > > > > * *
> > > > > > > > *Is this a known limitation of JBoss Rules (I am using JBOSS
> > > > > > > > Rules 3.0.6) or the JANINO compiler?*
> > > > > > > > * *
> > > > > > > > *Thanks.*
> > > > > > > > *
> > > > > > > >
> > > > > > > > package
> > > > > > > > *
> > > > > > > > *com.sample;
> > > > > > > >
> > > > > > > > public
> > > > > > > > class Outer{ public class Inner { public boolean
> > > > > > > > inner =false; public class InnerInner {
> > > > > > > >
> > > > > > > > }
> > > > > > > >
> > > > > > > > }
> > > > > > > >
> > > > > > > > }
> > > > > > > > **package*
> > > > > > > > com.sample *
> > > > > > > >
> > > > > > > > import
> > > > > > > > *com.sample.Outer1.Inner.InnerInner; *
> > > > > > > >
> > > > > > > > rule
> > > > > > > > *"Hello World 1" *when*
> > > > > > > >
> > > > > > > > InnerInner()
> > > > > > > > *then*
> > > > > > > >
> > > > > > > > System.out.println(
> > > > > > > > "");* *
> > > > > > > >
> > > > > > > > *end*
> > > > > > > >
> > > > > > > > ------------------------------
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > 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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > 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
> > > > > Software Engineer - JBoss Rules Core Developer
> > > > > Office: +55 11 3529-6000
> > > > > Mobile: +55 11 9287-5646
> > > > > 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
> > > Software Engineer - JBoss Rules Core Developer
> > > Office: +55 11 3529-6000
> > > Mobile: +55 11 9287-5646
> > > JBoss, a division of Red Hat @ www.jboss.com
> > >
> >
> >
>
>
> --
> Edson Tirelli
> Software Engineer - JBoss Rules Core Developer
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070706/4963e251/attachment.html
More information about the rules-users
mailing list