The easiest thing might be for me to have a look at the Bean class, and see if I can see a problem. If you don't want to share it with the list you can send it to me privately at [EMAIL PROTECTED] .
A future release of Jess is going to have to deal with this kind of issue. I've been thinking that maybe you could specify to Jess that certain properties are subject to spontaneous change and therefore shouldn't beused in indices. Furthermore, the hashCode()s of user-supplied Bean objects often don't behave the way they should, and a way that Jess could avoid the problem is by managing objects using Handles rather than directly --i.e., you wouldn't be allowed to say "undefinstance(x)." When you called definstance(x) you'd get back a return value y, and you could then say undefinstance(y). This is, I think, a small price to pay. It forces the user to manage the possibly changing objects, rather than having Jess do it. Of course, you can also use BeanInfo objects, something else we mentioned on this list recently. A BeanInfo can specify that only certain methods should be considered as properties, and others should be ignored; you could ignore the troublesome property this way. I think Tim Good wrote: > We are getting duplicate facts in our fact-base. The same > fact-id appears twice when we run (facts) and is output > twice in a (save-facts). Specific rules to examine the > facts; however, only see the fact once. One of each pair can > be retracted, but attempts to retract the remaining one fail > with no message. > > The facts are dynamic definstances of java objects. The > definstance and modification are done in a separate thread > from the rules execution. No specific hashcode or equals > method has been defined. > > The problem seems to be centered around modification of a > specific bean property which has given us problems in the past. > An earlier question (6/20) on a related issue got us this > response. > > Furthermore, be sure that the hashCodes of the Beans, and of the > objects they contain in their slots, do not change except as reported > in a property change event. A common problem is having a container > like a Set, Map or List as a Bean property. If data is added to the > Set, Map, or List, its hashCode will likely change. Since the hashCode > may have been used by Jess to organize facts in the Rete network, such > a change will corrupt Jess's data structures, and so from that point > on anything can happen. Bean properties should be simple value objects > like Strings and Integers. > > > The property is stored as a Map but passed as an array in its get > method and propertychange event. The set method is not implemented. We > thought it was taken care of at the time since it seemed to work but > recent code changes have brought it back. > > I am not sure what questions to ask at this point. It seems that our use > of the Map may be causing our problems. Can we use the map as a bean > property at all? Do we have to define our own hashcode and equals > method for the bean? How does Jess use the slot hashcodes? > > - Tim Good > --------------------------------------------------------- Ernest Friedman-Hill Distributed Systems Research Phone: (925) 294-2154 Sandia National Labs FAX: (925) 294-2234 Org. 8920, MS 9012 [EMAIL PROTECTED] PO Box 969 http://herzberg.ca.sandia.gov Livermore, CA 94550 -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
