[
http://jira.jboss.com/jira/browse/JBRULES-1268?page=comments#action_12381888 ]
Michael Neale commented on JBRULES-1268:
----------------------------------------
yes that is a good point. The problem is that the event listener exposes the activation
item in its API, thus the remove() is there.
AgendaFilter is really what this is for.
I would be happy with this to throw a UnsupportedOperationException - with clear error
message saying how you can't change the activation inside a event listener (and use a
filter instead).
Activation.remove() is removing the WRONG activation when used in
events
------------------------------------------------------------------------
Key: JBRULES-1268
URL:
http://jira.jboss.com/jira/browse/JBRULES-1268
Project: JBoss Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: Reteoo
Affects Versions: 4.0.2
Reporter: Michael Neale
Assigned To: Edson Tirelli
Priority: Critical
Fix For: 4.1.0
Check out FIXME_testActivationCancellation in MiscTest.java.
It shows how a call to activation.remove() for a given rule (in an event) actually
removed the wrong rule.
The reason for this is that fireNextItem in DefaultAgenda uses
BinaryHeapQueueAgendaGroup.getNext().
This poorly named "getNext()" actually calls dequeue on the queue, so when the
event is called, the activation has ALREADY been dequeued.
Not sure of best solution, other then a queue "peek()" and then dequeue() to be
called after then event is fired (if it wasn't called already).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira