[jboss-jira] [JBoss JIRA] Commented: (JBRULES-1152) my unit tests are hanging with drools 4.0.1

[Edson Tirelli (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 at 84cc09: display name [org.springframework.context.support.ClassPathXmlApplicationContext at 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 at 84cc09]: org.springframework.beans.factory.support.DefaultListableBeanFactory at 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 at 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

> my unit tests are hanging with drools 4.0.1
> -------------------------------------------
>
>                 Key: JBRULES-1152
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-1152
>             Project: JBoss Rules
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 4.0.1
>         Environment: Java 1.5, Mac OX X 10.4.10, Drools 4.0.1
>            Reporter: Steve Miner
>         Assigned To: Edson Tirelli
>             Fix For: 4.0.2
>
>         Attachments: drools1152.zip
>
>
> Sorry, I don't have very specific information.  Some of my project's unit tests are hanging with drools 4.0.1.  No error, just not completing.  I tried to debug a bit but could not figure it out.  Consider this an early warning until I can gather more info.
> Everything worked fine with 4.0 so I went back to that.

-- 
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