We are working on a solution using Topic JMS with spring, so we build
a RuleBase and
publish it as a 'post' with one topic, while the 'client' which is a
WorkingMemoryFactory is
listening on the topic all the time (configurable) so when the topic
is refreshed, the client
automagicaly refresh his own -singleton- RuleBase and (as is a
Factory) is able to returns
a newWorkingMemory from that RuleBase. We will send the code with
examples in few
weeks, I think.
Good Luck.
On 21-03-2007, at 9:01, jdepaul wrote:
I don't have an application in PROD yet, I'm just working on a
Proof of
Concept with Drools 3.1.0M1 and Spring 1.2.8 but I have a similar
situation
as you in that I'll need to periodically reload Rules without
restarting the
App. This is what I've discover will work for us - not sure in
your case,
but here it is:
I have objects called EventRuleBase objects which basically wrap
RuleBase
objects. Each instance of EventRuleBase object is tied to a
resource (*.drl
file on the file system for now, but in the future it may come from
a DB).
I then have a notion of RuleBaseManager object which is in charge of
managing the collection of EventRuleBase objects. I use Spring to
initialize and load all EventRuleBase objects individually and then
register
themselves with the RuleBaseManager object which records their
instances in
HashMap. The RuleBaseManager implements several methods:
getWorkingMemory(...) and ruleChange(newEventRuleBase). The
RuleBaseManager
is a Singleton and the EventRuleBase objects are NOT singletons....
In my testing, I've discovered that when it's time to reload rules
(some
type of triggering mechanism must invoke this), I can ask Spring
for a new
instance of the EventRuleBase object by name (i.e.
appContext.getBean(LOAD_rulebase) - it will fetch a brand new
object which
it will automatically reload from the underlying Resource (on the
filesystem) - note that "singleton=false" bean configuration in Spring
config is key for this. I can then hand the new instance of the new
EventRuleBase object to the ruleChange(newEventRuleBase) method
which it
will then synchronize and 'swap-in' the new object into the HashMap it
maintains. The clients that invoke subsequent getNewWorkingMemory
() methods
on the new EventRuleBase object will then start getting references
to new
object with NEW rules. I figured I'll need to protect the
integrity of the
hashmap using the JDK 1.5 implementation of ConcurrentHashMap which
is very
much possible using Spring 2.x - check out the documentation.
Hope this helps.
Regards -
James'
Carlos Henriquez wrote:
We want to change rules at runtime without redeploying the whole
application.
--
View this message in context: http://www.nabble.com/Changing-rules-
at-runtime-tf3392187.html#a9593359
Sent from the drools - user mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
Felipe Piccolini M.
[EMAIL PROTECTED]
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
