[ http://jira.jboss.com/jira/browse/JBRULES-1152?page=comments#action_12375448 ] Steve Miner commented on JBRULES-1152: -------------------------------------- I've made some progress debugging my unit tests. It looks like there's a new sensitivity to the order of the actions on the RHS when using Drools 4.0.1. If I make an ACU and setState("off") and setPowerButtonPressed(true) then fireAllRules(), both rules fire. I only expected the "PowerOn" rule to fire. If I reorder the RHS so that setPowerButton(false) happens first (see comments), then everything works as expected. I believe that the hang I originally reported was an oscillation in the system with multiple rules firing in cases where only one used to fire with Drools 4.0. rule "PowerOn" when $acu : ACU (powerButtonPressed == true , state == "off" ) then System.out.println("PowerOn fired"); // BEFORE WORKS $acu.setPowerButtonPressed(false); $acu.setState("SelectMode"); // AFTER FAILS $acu.setPowerButtonPressed(false); end rule "PowerOff" when $acu : ACU (powerButtonPressed == true, state != "off" ) then System.out.println("PowerOff fired"); //BEFORE WORKS $acu.setPowerButtonPressed(false); $acu.setState("off"); // AFTER FAILS $acu.setPowerButtonPressed(false); end -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-1152?page=comments#action_12375580 ] Michael Neale commented on JBRULES-1152: ---------------------------------------- comment... hmmm punting to edson to see if this is something to do with shadow facts. this is very strange - I don't recall modify being woven in automatically. try putting modify($acu); on the last line, see if that helps. -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-1152?page=comments#action_12375658 ] Michael Neale commented on JBRULES-1152: ---------------------------------------- Yes dynamic beans would have a huge effect on this ;) good to know. well await more details, but I think there are a lot of clues in there. -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-1152?page=comments#action_12376196 ] Steve Miner commented on JBRULES-1152: -------------------------------------- I haven't been able to come up with a simple example that isolates the issue. My environment also involves Spring Framework 2.0.6 using AOP. Could there be an issue with AOP proxy wrappers on the Java Beans? -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-1152?page=all ] Steve Miner updated JBRULES-1152: --------------------------------- Attachment: drools1152.zip Attached is a zip of my Eclipse project that includes the Spring Framework jars. It demonstrates a conflict with the Spring AOP. You need to add the Drools jars to the build path (not included). If you run the main in DroolsTest.java, it will get a null-pointer exception. Edit spring.xml to comment out the line the loads the AspectManager (which uses AOP), and run DroolsTest again. Now it works normally. This is not exactly what I was seeing when I first reported this bug, but it points to some sort of conflict with Spring AOP. Surprisingly, this example still has problems with Drools 4.0, which I do not see with my original (much bigger) project. -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-1152?page=all ] Michael Neale reassigned JBRULES-1152: -------------------------------------- Assignee: Edson Tirelli (was: Michael Neale) Punting to edson as this is probably shadow fact related. -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-1152?page=comments#action_12376642 ] Steve Miner commented on JBRULES-1152: -------------------------------------- I modified my example not to use the bean property listener, and do an explicit update() in the RHS of the rules (using the default Java dialect), and it worked as expected. I also used a variation with the mvel dialect as suggested (without the bean property listener) and that also worked as expected. So those options sound like work-arounds, but I have an existing body of rules that use dynamic facts and I'd like to get them working again out of the box. Over time, I'm willing to transition to the suggested style for better performance but it's not practical in the short time. Also, the documentation should mention this issue about the performance of dynamic facts. -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-1152?page=comments#action_12376867 ] Edson Tirelli commented on JBRULES-1152: ---------------------------------------- Ok, I debugged the provided project and found 3 items worth of note: 1. The interference of Spring. The main problem we see in this example, is that as it is coded, one object is inserted into working memory, but another object is the "source" of the events in the PropertyChangeSupport. This happens because in the constructor of the Message class, there is the following code: public Message() { propertySupport = new PropertyChangeSupport(this); } So, a reference to "this" (in my eclipse debug, the instance is: object Message (id=4204)) is set as the source of PropertyChangeSupport. Although, the instance inserted into the working memory is: Message message = (Message)context.getBean("myMessage"); workingMemory.insert( message, true ); Where "message" instance is: message Message$$EnhancerByCGLIB$$3ae0902b (id=4099) So, when the property change is fired with event source "(object Message (id=4204))", the object is not found in the working memory (identity search), since it was never inserted. As a proof, a simply changed the code, adding a method to the message class: // added to Message class public void init( Object source ) { propertySupport = new PropertyChangeSupport(source); } And changed the calling code to: Message message = (Message)context.getBean("myMessage"); // now, the property change support is initialized with the reference // to the object returned by Spring, instead of the "this" reference message.init( message ); workingMemory.insert( message, true ); workingMemory.fireAllRules(100); After this change, as expected, everything is working. 2. The NullPointerException: the scenario above was causing a NPE in the engine, what is suboptimal. So, I fixed the engine to not raise NPE anymore, and instead, raise a more appropriate message. 3. The rules you were using in your test are causing an infinite loop, and that is the reason your tests are hanging. If you limit the number of rules to fire or remove the infinite loop, you will see that the engine behaves as expected. Example: to show the execution of 5 activations, just do: workingMemory.fireAllRules(5); After running the example, the result is: Sep 14, 2007 11:50:07 AM org.springframework.context.support.AbstractApplicationContext prepareRefresh INFO: Refreshing org.springframework.context.support.ClassPathXmlApplicationContext@84cc09: display name [org.springframework.context.support.ClassPathXmlApplicationContext@84cc09]; startup date [Fri Sep 14 11:50:07 BRT 2007]; root of context hierarchy Sep 14, 2007 11:50:07 AM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions INFO: Loading XML bean definitions from class path resource [com/sample/spring.xml] Sep 14, 2007 11:50:08 AM org.springframework.context.support.AbstractApplicationContext obtainFreshBeanFactory INFO: Bean factory for application context [org.springframework.context.support.ClassPathXmlApplicationContext@84cc09]: org.springframework.beans.factory.support.DefaultListableBeanFactory@93df2c Sep 14, 2007 11:50:08 AM org.springframework.context.support.AbstractApplicationContext$BeanPostProcessorChecker postProcessAfterInitialization INFO: Bean 'org.springframework.aop.config.internalAutoProxyCreator' is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying) Sep 14, 2007 11:50:08 AM org.springframework.beans.factory.support.DefaultListableBeanFactory preInstantiateSingletons INFO: Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@93df2c: defining beans [org.springframework.aop.config.internalAutoProxyCreator,aspectManager,myMessage]; root of factory hierarchy PowerOn fired aroundChange before setting: state aroundChange after setting: state aroundChange before setting: message aroundChange after setting: message aroundChange before setting: state aroundChange after setting: state PowerOff fired aroundChange before setting: state aroundChange after setting: state aroundChange before setting: message aroundChange after setting: message aroundChange before setting: state aroundChange after setting: state PowerOn fired aroundChange before setting: state aroundChange after setting: state aroundChange before setting: message aroundChange after setting: message aroundChange before setting: state aroundChange after setting: state PowerOff fired aroundChange before setting: state aroundChange after setting: state aroundChange before setting: message aroundChange after setting: message aroundChange before setting: state aroundChange after setting: state PowerOn fired aroundChange before setting: state aroundChange after setting: state aroundChange before setting: message aroundChange after setting: message aroundChange before setting: state aroundChange after setting: state done Thanks for reporting. Let me know if you have any question. Edson -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-1152?page=comments#action_12376891 ] Steve Miner commented on JBRULES-1152: -------------------------------------- Thanks for finding the AOP bug in my example. That was an oversight by me when I was trying to code up an isolated example. We actually do the right thing in our project. I also left a few extra actions in my rules. I've fixed those problems and will send a new slightly modified example. I still see a sensitivity to the order of the actions in the RHS when both Spring AOP and Drools 4.0.1 are used. The sensitivity does not exist with Drools 4.0, or when 4.0.1 is used without Spring AOP. Updated example to follow. -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-1152?page=comments#action_12377068 ] Michael Neale commented on JBRULES-1152: ---------------------------------------- I would hazard a guess that it was only luck that it worked as expected in 4.0.0. It has happened before ;) -- 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

[ http://jira.jboss.com/jira/browse/JBRULES-1152?page=comments#action_12381190 ] Steve Miner commented on JBRULES-1152: -------------------------------------- I confirmed that Drools 4.0.2 fixes my problem. Also, my original unit tests now work again as they did with 4.0. -- 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