I've attached a simple stand-alone example to the ticket.
--
View this message in context:
http://drools.46999.n3.nabble.com/5-3-0-CR1-has-broken-existing-rules-flows-tp3390922p3398007.html
Sent from the Drools: User forum mailing list archive at Nabble.com.
I have found that any serious Drools application should write and deploy a
consequence exception handler of its own. Perhaps you look at my modest
efforthttp://members.inode.at/w.laun/drools/CustomConsequenceExceptionHandlingHowTo.html-
I think it is still compatible. Any feedback welcome ;-)
-W
October 2011 08:42
To: Rules Users List
Subject: Re: [rules-users] 5.3.0 CR1 has broken existing rules/flows
I have found that any serious Drools application should write and deploy a
consequence exception handler of its own. Perhaps you look at my modest
efforthttp://members.inode.at/w.laun
-boun...@lists.jboss.org
[mailto:rules-users-boun...@lists.jboss.org] *On Behalf Of *Wolfgang Laun
*Sent:* 04 October 2011 08:42
*To:* Rules Users List
*Subject:* Re: [rules-users] 5.3.0 CR1 has broken existing rules/flows
I have found that any serious Drools application should write and
deploy
Thanks for all of the feedback. I haven't tried W's handler, but I'm
planning to. I did take Edson's advice and was able to get some more info.
It appears to involve the interaction between 3 rules. For background, this
is a fraud detection application. Under certain conditions, we need to
Just saw and fixed an invalid import for ConsequenceExceptionHandler.
-W
On 4 October 2011 18:00, Jamie js...@llbean.com wrote:
Thanks for all of the feedback. I haven't tried W's handler, but I'm
planning to. I did take Edson's advice and was able to get some more info.
It appears to
The difference in that area from 5.2 to 5.3 is that in 5.3 the
interaction between Terminal Nodes and the agenda was refactored into a
listerner pattern . This is required for future features we are working
on. It seems the change introduced the regression.
This is probably enough info to
definitely a much improved handler. in case someone who reads this is using
spring to load droools, here is an example of loading a different handler
for a knowledge base in the xml:
drools:kbase id=workflowKnowledgeBase node=droolsClusterNode1
On 04/10/2011 20:17, Edson Tirelli wrote:
The difference in that area from 5.2 to 5.3 is that in 5.3 the
interaction between Terminal Nodes and the agenda was refactored into
a listerner pattern . This is required for future features we are
working on. It seems the change introduced the
One way of helping isolating the problem is to set a break point for a
NullPointerException. When the exception is raised do 2 things:
1. In the RuleTerminalNode where the NPE is generated, check the content of
the rule attribute. This will tell you the offending rule.
2. Check which
This is very good info. I have found those Drools ConsequenceExceptions a
real PITA to troubleshoot. I wonder if the exception could be enhanced to
show this info so users don't have to debug it? I mean, to have the
exception message show the true culprit rule name, or something useful like
11 matches
Mail list logo
