[jboss-jira] [JBoss JIRA] Commented: (JBRULES-740) IncompatibleClassChangeError working with ShadowProxy

[Dirk Bergstrom (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBRULES-740?page=comments#action_12357005 ] 
            
Dirk Bergstrom commented on JBRULES-740:
----------------------------------------

It happens that all of my classes have an "id" attribute, which is
their record number in the external datasource.  They also have the
"lastModified" time from the datasource.  This means that "equals" is
(potentially) very simple: the "primary key" is id + lastModified.

Given that I know how to define "equals", and that I know that I'm
going to be shoving my class into a rules engine, I'm perfectly
willing to give the rules engine whatever help it needs.  I have *no*
"religion" about pojos, I'm happy to add methods or fields to my
classes to help Drools -- the entire class is written for use in
Drools.

The simplest thing might be to have a public static final String[]
that lists the fields used to define equality and hashcode.  That
would save Drools the trouble of digging around with ASM trying to
figure out what's going on.  It should be fairly easy to document the
situations where the use of this is appropriate and/or necessary.
That way users could decide what to do, and the ones who insist on
pojos can take their chances.

I prefer something explicit that works, rather than something implicit
and tricky that sometimes fails in strange ways deep in the guts of a
library.

> IncompatibleClassChangeError working with ShadowProxy
> -----------------------------------------------------
>
>                 Key: JBRULES-740
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-740
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.1-m2
>         Environment: Trunk (revision 10170)
>            Reporter: Dirk Bergstrom
>         Assigned To: Edson Tirelli
>             Fix For: 3.1-m2
>
>         Attachments: Record.java, RLIRecord.java, stacktraces.txt
>
>
> I'm getting an exception while asserting objects into the working memory.  Depending on the timing, I get different stacktraces leading up the same exception on the same generated class.  I have 15 rules and three types of objects in the working memory.  2500 User objects, 37 Milestone objects, and 2000 RLI objects.  If I assert all the Users and Milestones first, I get the first exception below during assertion of the RLI objects, at the 257th object asserted.  If I arrange to skip that particular record, I can assert a few more before another record trips the bug.  If I put a try/catch block around the assertion and continue after hitting an exception, I can assert about 1600 of the records successfully, and the others reliably throw (ie. if I try to assert them later).  If I assert RLIs first, I get the second stacktrace during assertion of Milestones.  Looks like the problem happens during execution of one or more rules.  I'll attach the RLI class, and its parent class (which is also the parent of the other two classes).
> Exception in thread "RLIs Processor" java.lang.IncompatibleClassChangeError
> 	at net.juniper.dash.data.RLIRecordShadowProxy.hashCode(Unknown Source)
> 	at java.util.HashMap.put(HashMap.java:418)
> 	at java.util.HashSet.add(HashSet.java:194)
> 	at org.drools.reteoo.CollectNode.assertTuple(CollectNode.java:135)
> 	at org.drools.reteoo.CollectNode.assertObject(CollectNode.java:212)
> 	at
> org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
> 	at
> org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:304)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:176)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:121)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
> 	at
> org.drools.reteoo.ReteooWorkingMemory.doAssertObject(ReteooWorkingMemory.java:68)
> 	at
> org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:729)
> 	at
> org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:548)
> Exception in thread "Milestones and NPI Processor" java.lang.IncompatibleClassChangeError
> 	at net.juniper.dash.data.RLIRecordShadowProxy.hashCode(Unknown Source)
> 	at java.util.HashMap.put(HashMap.java:418)
> 	at java.util.HashSet.add(HashSet.java:194)
> 	at org.drools.reteoo.CollectNode.assertTuple(CollectNode.java:135)
> 	at org.drools.reteoo.CompositeTupleSinkAdapter.propagateAssertTuple(CompositeTupleSinkAdapter.java:30)
> 	at org.drools.reteoo.JoinNode.assertTuple(JoinNode.java:116)
> 	at org.drools.reteoo.SingleTupleSinkAdapter.createAndPropagateAssertTuple(SingleTupleSinkAdapter.java:55)
> 	at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:147)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:145)
> 	at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:20)
> 	at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:176)
> 	at org.drools.reteoo.Rete.assertObject(Rete.java:121)
> 	at org.drools.reteoo.ReteooRuleBase.assertObject(ReteooRuleBase.java:196)
> 	at org.drools.reteoo.ReteooWorkingMemory.doAssertObject(ReteooWorkingMemory.java:68)
> 	at org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:729)
> 	at org.drools.common.AbstractWorkingMemory.assertObject(AbstractWorkingMemory.java:548)
> 	at net.juniper.dash.data.DataSource.reconcileAssertedRecords(DataSource.java:190)
> 	at net.juniper.dash.data.DataSource.populateRecords(DataSource.java:150)
> 	at net.juniper.dash.Updater$DataSourceProcessor.work(Updater.java:181)
> 	at net.juniper.dash.Refresher.run(Refresher.java:70)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira