[rules-dev] NPE with nested patterns

Mario Fusco mario.fusco at gmail.com
Thu Mar 15 05:04:28 EDT 2012


Mauricio,

I am seeing exactly what you wrote.
What I have found until now is that the harming pattern is inside the last
and block (the one starting at line 218 of the single big rule and ending
at 235), indeed if you comment away that block the test succeeds.

I'll keep you updated on my further findings.

Mario

On Thu, Mar 15, 2012 at 9:53 AM, Mauricio Salatino <salaboy at gmail.com>wrote:

> Mario, I was looking at that problem too.
> Notice that if you remove some of the ANDs, the rule will work without
> throwing the null pointer exception.
> Which makes me think that it could be related with the number of
> declarations or how the patterns are being arranged for that specific case.
> The null pointer is raised when a hashcode is being calculated for a
> declaration that doesn't have an object assigned, for some reason it's not
> there.
> One of the tests shows how we have splitted the rule in multiple rules
> showing that each individual group of patterns is correct.. which make me
> think again about the number of patterns and/or declarations can be causing
> the issue.
>
> Cheers
>
> Keep us posted about your findings.. we can probably learn how to solve
> these problems and stop bothering you :)
>
>
> On Thu, Mar 15, 2012 at 8:39 AM, Mario Fusco <mario.fusco at gmail.com>wrote:
>
>> I am going to give a look at it.
>>
>> On Thu, Mar 15, 2012 at 9:11 AM, Esteban Aliverti <
>> esteban.aliverti at gmail.com> wrote:
>>
>>> Hi Guys,
>>> I'm having a NPE in one of the rules I'm using and I can't find the
>>> cause.
>>> I'm attaching a test project that shows the problem.
>>> Basically, I have 1 rule that contains some nested 'ands' and 'ors'
>>> patterns. The rule is being auto-generated from some data, that is why it
>>> has this strange structure.
>>> We tried to refactor the rule by separating it in different
>>> rules, extract some common factors, etc. and in some cases it works.
>>> So I'm not sure whether the original rule is wrong or if I'm hitting a
>>> bug in Drools.
>>> Inside the test project you can find the original rule
>>> (SimpleHighRiskSepsis.drl) and all the other refactors we did.
>>>
>>> Best Regards,
>>>
>>> XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>>>
>>> Esteban Aliverti
>>> - Developer @ http://www.plugtree.com
>>> - Blog @ http://ilesteban.wordpress.com
>>>
>>> _______________________________________________
>>> rules-dev mailing list
>>> rules-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-dev
>>
>>
>
>
> --
>  - MyJourney @ http://salaboy.wordpress.com
>  - Co-Founder @ http://www.jugargentina.org
>  - Co-Founder @ http://www.jbug.com.ar
>
>  - Salatino "Salaboy" Mauricio -
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20120315/5dbcf6a9/attachment.html 


More information about the rules-dev mailing list