[
https://jira.jboss.org/jira/browse/JBRULES-2229?page=com.atlassian.jira.p...
]
Edson Tirelli resolved JBRULES-2229.
------------------------------------
Fix Version/s: 5.1.0.M1
Resolution: Done
Problem is fixed in revision #28861.
The problem was that to be able to have drools-api and still be backward compatible with
Drools 4 API, there is some magic going on with user exposed classes wrapping internal
classes for API compatibility. The problem is that in this case, the method:
drools.getKnowledgeRuntime()
was returning a new instance of stateful session wrapper, that did not had access to
previously set listeners. I.e., caching problem. I removed the caches and used an
equals/hashcode methods delegation to be able to fix the problem.
Let me know if you still have any issue, but by my tests it is working fine now.
Unable to remove an event listener from within the RHS of a rule
----------------------------------------------------------------
Key: JBRULES-2229
URL:
https://jira.jboss.org/jira/browse/JBRULES-2229
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-core (expert)
Affects Versions: 5.0.1.FINAL
Reporter: Michael Neale
Assignee: Edson Tirelli
Priority: Critical
Fix For: 5.1.0.M1
Attachments: test.zip
Hey Edson - was working with Solnet - they cam across this one. I have been able to
reproduce it. They are asserting a listener itself as a fact, and then trying to remove
this in the RHS of some rule (see attached test).
interestingly, if you remove the SAME instance of the listener in regular code, it works
just fine.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira