That sounds exactly right, we did indeed try and modify the OBJECT slot, and yes it failed in a pretty emphatic way. I'm pretty sure we got it right because other slot modifications using the same mechanism worked correctly.
We're currently getting our license and will work on this integration the moment we do. Thanks a lot, Will Edwards -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ernest Friedman-Hill Sent: Tuesday, December 11, 2007 9:46 AM To: [email protected] Subject: Re: JESS: Updating shadow facts from object copies Hi Will, There are three parts of this problem: 1) Given the copied object, identifying the existing object that corresponds to it. This could be tricky unless the objects have some kind of id. You didn't mention this being a problem, so I'm going to assume it's solved. 2) Updating the shadow fact so that it refers to the new object. Technically this shouldn't be hard -- the OBJECT slot could theoretically just be modified like any other slot. Unfortunately there's going to be a problem: if you tried this on a static definstance (which I'll assume yours are), Jess would try to set the OBJECT property of the object itself, and presumably this would fail spectacularly. 3)Besides the OBJECT slot, Jess also keeps a map which associates each definstanced object with its shadow fact; that's so Jess can quickly handle propertyChange events, undefinstance() calls, etc. where you pass in the object and Jess needs to find the fact. There's no public API for changing this map directly. Now, the nice thing is that Jess is licensed in source code form, and you can make your own modifications. Appropriate mods for this would really be pretty simple. To handle (3), you could add a method something like this to jess/ DefinstanceList.java void useNewObject(Rete engine, Object newObject, Object oldObject) { synchronized (engine.getWorkingMemoryLock()) { Fact fact = (Fact) m_definstances.get(oldObject); if (fact != null) { m_definstances.remove(oldObject); m_definstances.put(newObject, fact); } // else maybe throw a JessException } } Also add a package-protected method to Rete which forwarded calls to m_factList. To handle (2), you'd want to add special cases to jess/FactList.java for a property named OBJECT. In modifyDefinstancedFact(), you'd want to call your method on Rete to change the lookup object instead of setting the object's property the way it does now. You'd also want to call modifyRegularFact directly from modifyDefinstanceFact() to change the OBJECT slot itself. On Dec 11, 2007, at 8:38 AM, Will Edwards wrote: > Wolfgang is correct, we have a single Rete instance. He is also > correct in > that we can always obtain a reference to the original object via > the shadow > fact, or some other way. > > The problem is that when an update happens to an object a new copy > of the > updated object is passed. So, we have two physical objects that > represent > the same logical piece of data, say A1 that is already in Rete as a > shadow > fact, and A2 the updated version of A1 that has just been passed to > us. > > My question was: what is the best, or simplest, way to update Rete > with the > new object. > > Thanks. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:owner-jess- > [EMAIL PROTECTED] On > Behalf Of Wolfgang Laun > Sent: Tuesday, December 11, 2007 4:48 AM > To: [email protected] > Subject: Re: JESS: Updating shadow facts from object copies > > I have understood Will's problem to be within a single Rete object. > Basically, the Rete.add() method returns a reference to the created > jess.Fact. As a shadow fact in good standing it'll have a slot OBJECT > containing a reference to the original Java object. "Therefore, the > original object is always easily available." (The Jess Manual, 5.3.2) > > Hal Hildebrand wrote: > >> Wouldn't the fact id be (potentially) different in different >> instances of the rules engine? I believe these are assigned in >> declaration order, so unless every instance is defining instances in >> precisely the same order, then you'd end up with the same logical >> fact having different ids in different VMs. >> >> FWIW, there's a good paper by someone who did something remarkably >> similar: www.waset.org/pwaset/v4/v4-18.pdf >> >> Myself, I've taken another route, which is using shadow facts for >> everything I want distributed. The facts all have generated UUIDs, >> so there's no issues with locally generated ids in a distributed >> system. Then it's a fairly simple matter to translate to the local >> facts when the shadow changes and vice versa. >> >> On Dec 10, 2007, at 1:07 PM, Will Edwards wrote: >> >>> We're attempting to integrate a JavaSpaces implementation with Jess. >>> >>> When an object changes in the JavaSpace we receive a notification >>> that the >>> object has changed and a copy of the changed object which we want to >>> add or >>> modify as a Jess shadow fact in the rules engine. >>> >>> Our problem is that in this environment we do not get a reference to >>> the >>> original object but a new (by value) copy of the object. So, we >>> want to >>> modify the existing Jess fact with the new copy. Assuming we have >>> the >>> FactIDValue (from the original rete.add) is there a reasonably >>> simple way to >>> do this? >>> >>> Currently we are using a FactFilter to get the existing object, call >>> rete.remove() to remove the old copy and then rete.add() with the >>> new copy. >>> This is of course prone to potential race conditions, etc. >>> >>> What we would like to do is use modify() or updateObject() but both >>> of these >>> seem to require that the original object reference be maintained. >>> >>> Thanks in advance. >>> >>> -------------------------------------------------------------------- >>> 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] . >>> -------------------------------------------------------------------- >>> >> >> -------------------------------------------------------------------- >> 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] >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > 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 owner-jess- > [EMAIL PROTECTED] > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > 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 owner-jess- > [EMAIL PROTECTED] > -------------------------------------------------------------------- --------------------------------------------------------- Ernest Friedman-Hill Informatics & Decision Sciences Phone: (925) 294-2154 Sandia National Labs FAX: (925) 294-2234 PO Box 969, MS 9012 [EMAIL PROTECTED] Livermore, CA 94550 http://www.jessrules.com -------------------------------------------------------------------- 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] -------------------------------------------------------------------- -------------------------------------------------------------------- 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] --------------------------------------------------------------------
