[rules-users] PropertyChangeListeners vs. modify()

[Mark Proctor]

W00t I found the code, I committed it after all. Check out the follow code:

JavaFact
DelegateJavaFactHandler
JavaFactRegistryEntry
DelegateJavaFactHandlerTest

So JavaFact is the interface with the following methods
    JavaFactRegistryEntry[] listWorkingMemories();
    boolean register(final WorkingMemory workingMemory);
    unregisterAll();
    boolean unregister(final WorkingMemory workingMemory);
    boolean isRegistered(final WorkingMemory workingMemory);
    public int[] getChanges();  

At load time this interface is woven into each class. It allows 
constructed objects to be monitored by one or more working memories. 
There is a DelegateJavaFactHandler implementation to save you writting 
all the code, the weaving just delegates each method call to this 
delegate. Probably ignore the getChanges() part, I think that was part 
of a plan to batch changes for a single modify (for efficiency), for now 
probably the easiest thing is to just iterate the working memories 
calling modify on each set. All this code is very experimental and 
subject to change :)

Mark
Mark Proctor wrote:
> Barry,
>
> I started a project like this, but lost the code :( The idea was to 
> hava JavaFact interface that allowed a bean to register one or more 
> working memories, and it would "notify" all working memories on 
> change. The JavaFact interface would be woven into the beans at load 
> time. I was going to take it one step further to allow systems like 
> Spring to control the "monitoring", i.e. the spring conf file would 
> specify which working memories would be registered on beans during 
> construction - so spring can manage the full life cycle of working 
> memories and facts, invisibly to the user. Maybe you could work on 
> re-doing this work for ? :)
>
> Mark
> Barry Kaplan wrote:
>> I'm working on an implementation that uses AspectJ to introduce the 
>> required property change listeners. However the listeners will only 
>> trigger when the rule when clause exits (using after advice).
>>
>> This is just an experiment now, as I'm not sure how appropriate 
>> deferring the property change events (and hence the calls to modify) 
>> for /all/ facts till end-of-when will work out. I suspect it will be 
>> application dependent.
>>
>> -barry
>>
>> Edson Tirelli wrote:
>>>   Controversial some times, but I play on your team. Never used PCL 
>>> in my applications. :)
>>>
>>>   []s
>>>   Edson
>>>
>>> Dirk Bergstrom wrote:
>>>
>>>> Reading through the sources, it looks like property change 
>>>> listeners simply end
>>>> up calling modify().  This implies that you're better off not using 
>>>> them if
>>>> you'll be changing more than one property at a time, since you'll 
>>>> just be
>>>> calling modify() a bunch of times.  Better to change all the 
>>>> properties, then
>>>> call modify() once.
>>>>
>>>> Is this a fair reading, or am I missing something?
>>>>
>>>>  
>>>>
>>>
>>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>