* 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

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(a)codehaus.org&gt; 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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users > > > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

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(a)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(a)gmail.com&gt; 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(a)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(a)lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > _______________________________________________ > > > rules-users mailing list > > > rules-users(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > _______________________________________________ > > rules-users mailing list > > rules-users(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > _______________________________________________ > rules-users mailing list > rules-users(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

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(a)gmail.com&gt;: > > 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(a)post.com&gt; 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(a)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(a)gmail.com&gt; 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(a)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(a)lists.jboss.org > > > > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rules-users mailing list > > > > > rules-users(a)lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rules-users mailing list > > > > rules-users(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > _______________________________________________ > > > rules-users mailing list > > > rules-users(a)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(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > _______________________________________________ > rules-users mailing list > rules-users(a)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

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(a)gmail.com&gt;: > > 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(a)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(a)gmail.com&gt;: > > > > > > 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(a)post.com&gt; 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(a)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(a)gmail.com&gt; 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(a)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(a)lists.jboss.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rules-users mailing list > > > > > > > rules-users(a)lists.jboss.org > > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > rules-users mailing list > > > > > > rules-users(a)lists.jboss.org > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rules-users mailing list > > > > > rules-users(a)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(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > _______________________________________________ > > > rules-users mailing list > > > rules-users(a)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

Hello, Any ideas on what might be causing the error I am seeing? I seem to get this error only on inner classes that are defined within other inner classes. We have some fairly complex schemas for which XML Beans generates deeply nested hierarchies of inner classes. Any suggestions would be welcome. Thanks, Narendra On 7/5/07, Edson Tirelli <tirelli(a)post.com&gt; 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(a)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(a)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(a)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(a)lists.jboss.org > > > > > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rules-users mailing list > > > > rules-users(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > > > > > _______________________________________________ > > > rules-users mailing list > > > rules-users(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > > > _______________________________________________ > > rules-users mailing list > > rules-users(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users