]
Kris Verlaenen resolved JBRULES-14.
-----------------------------------
Fix Version/s: 3.0.6
(was: 4.0.0.MR4)
Resolution: Done
AuditEventListener
------------------
Key: JBRULES-14
URL:
http://jira.jboss.com/jira/browse/JBRULES-14
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Eclipse IDE, Reteoo
Reporter: Mark Proctor
Assigned To: Kris Verlaenen
Fix For: 3.0.6
Attachments: screenshot-1.jpg
The event model is split into 3. WorkingMemory, Reteoo, Agenda.
The WorkingMemory has three events
ObjectAsserted
ObjectRetracted
ObjectModified
The Agenda has 4 events
BeforeActivationFire
AfterActivationfired
ActivationCreated
ActivationCancelled
All events take a PropagationContext - this tells you if the event was the result of an
assertion, retraction or modification, it also tells you what the parent rule/activation
was.
You can use all this information to display a very useful tree.
We create two new listeners AgendaAuditListener and WorkingMemoryAuditListener - a
WorkingMemory listener is useless without the Agenda one being added. Each time when
BeforeActivationFired fires we attach the event to the tree, as we know the parent from
the PropagationContext. If the parent is null then we know there was a WorkingMemory
action (assert, retract, modify) from outside of a rule. So this allows us to create a
tree view of activation firing.
Second to this we should make it possible to record all asserted, retracted and mofied
objects during the evaluation of the Consequence. This is simply a matter of hooking into
each WM event and attaching it to the Activation in the tree, or possibly the WM action in
the tree.
If users just add the AgendaAuditView all it does is record the activation firing, if
they add the WorkingMemoryAuditListener it by default captures all three events - but we
allow users to specify which ones it captures, if they want. Secondly to this the view
itself should allow users to hide and show some events, ofcourse if that event was not
captured they should not be able to show it.
To create the Activation Tree I would do the following. + shows it has children - shows
it doesn't.
+ActivationFired
+ Assertion
-ActivationCreated
+ActivationCreated
+ActivationFired .....
.....
-Assertion
+Retraction
-ActivationCancelled
-ActivationCancelled
When users select the ActivationCancelled event it can show where the ActivationCreated
was added, and vice versa.
However if we do not capture WM events then the activations should just be attached to
the parent Activation
ActiationFired
+ActivationCreated
-ActivationFired
-ActivationCreated
-ActivationCancelled
Secondly we will need to implement a system to capture the relevant info. A range of
options are possible here, a simple "toString" capture, using the cloneable
interface, serialisation, the Memento snapshop pattern or maybe some sort of JavaBean
wrapper around a hashmap.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: