Hi, Thanks for the quick answer! The configuration you describe actually works fine. My issue is that I'm using objects where the equals method throws an exception when 2 objets are not of the same type. (which is far from being ideal, I must admit, but I don't have much control on these classes in my context) I assert these objects using the assertObject() method (no logical assert) I thought that the Identity behavoir will prevent JBoss Rules from calling equals() at all. Apparently this is not the case, I understand that this behavior allows to have A!= B and A.equals(B) and still put the 2 objects in the working memory, but the equals() method is still invoked for other purposes. Is there any way to fully prevent JBoss Rules from calling equals() on the facts to avoid potential exceptions? (I do realise that correcting the equals() method on the fact objects would make much more sense... ) With your explaination below, I don't have much hope, but I still give it a shot :-) Thanks Guillaume mercredi 24 janvier 2007 2:58 To: Guillaume TARDIF/fr/socgen@socgen cc: From: tirelli(a)post.com Subject: identity vs equality question - drools use of equals() Guillaume, This is a complex part of the engine, so we need to understand better what problems you are finding. Just as an overview, we have 2 separate types of check we need to do in the engine. One for normal asserted objects (identity by default) and one for logically asserted objects (equals by default). So, when you assert an object into working memory, we will decide asserting it or not, based on identity, but we will also update the TruthMaintenanceSystem with the object information (that is equals() based) with your newly asserted object. So, equals() WILL be called anyway, but it does not mean that the engine is not working on WM_IDENTITY_BEHAVIOR. So, if you don't use logical asserts, you don't need to worry with the results of your equals method. If you do use normal asserts and logical asserts, then there are some interactions that may need additional attention. A simple test you can do to check if the engine is indeed working fine is just create 2 different objects whose equals/hashcode methods evaluate to true/equals and assert both into working memory with normal assert method. Both instances will be added to the working memory. Can you ellaborate on the problem you are seeing? []s Edson guillaume.tardif(a)sgcib.com wrote: >Hi, > >I have a similar problem when using objects from an external framework >as facts : the equals method is invoked despite using the >/WM_BEHAVIOR_IDENTITY/property. > >Here is an exmple reproducing this with JBoss Rules 3.0.5 : I have >created a JBoss Rules project under Eclipse, and created 2 classes >MyObject and MyObject2. >These classes have hashCode() returning 0 and equals throwing a >ClassCastException when comparing 2 object of different classes > > > >Actually, after debugging a bit, it seems that the equals method is >invoked by the TruthMaintenanceSystem.assertMap, which has a hardcoded >EqualityKeyComparator (never set to IdentityKeyComparator). >The WorkingMemory.assertMap has its KetComparator set correctly to >IdentityKeyComparator >Also, the equals method is not called when the hashCode() method >returns different values for different objects, which makes it a bit >harder to reproduce the issue. > >This is a roadblock for using JBoss Rules in our context ; has someone >any idea for a workaround? > >Thanks in advance, >Guillaume > >************************************************************************* >This message and any attachments (the "message") are confidential and > > intended solely for the addressee(s). >Any unauthorised use or dissemination is prohibited. E-mails are > > susceptible to alteration. >Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall > > be liable for the message if altered, changed or falsified. > ************ >Ce message et toutes les pieces jointes (ci-apres le "message") sont > > confidentiels et etablis a l'intention exclusive de ses >destinataires. Toute utilisation ou diffusion non autorisee est interdite. > > Tout message electronique est susceptible d'alteration. >La SOCIETE GENERALE et ses filiales declinent toute responsabilite au > > titre de ce message s'il a ete altere, deforme ou falsifie. >************************************************************************* > > >------------------------------------------------------------------------ > >java.lang.ClassCastException > at com.sample.MyObject.equals(MyObject.java:7) > at org.drools.common.EqualityKey.equals(Unknown Source) > at org.drools.common.EqualityKeyComparator.areEqual(Unknown Source) > at org.drools.util.FastMap.getEntry(Unknown Source) > at org.drools.util.FastMap.get(Unknown Source) > at org.drools.common.TruthMaintenanceSystem.get(Unknown Source) > at org.drools.common.AbstractWorkingMemory.assertObject(Unknown > > Source) > at org.drools.common.AbstractWorkingMemory.assertObject(Unknown > > Source) > at com.sample.DroolsTest.main(DroolsTest.java:28)= > > > -- Edson Tirelli Software Engineer - JBoss Rules Core Developer Office: +55 11 3124-6000 Mobile: +55 11 9218-4151 JBoss, a division of Red Hat @ www.jboss.com