Re: [rules-users] PropertyChangeListeners vs. modify()
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users