But wait a second..
If you comment out another and inside the rule it will also work.. that
means that it's not the pattern inside the last AND
On Thu, Mar 15, 2012 at 9:04 AM, Mario Fusco <mario.fusco(a)gmail.com> wrote:
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(a)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(a)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(a)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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/rules-dev
>>>
>>>
>>
>> _______________________________________________
>> rules-dev mailing list
>> rules-dev(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
_______________________________________________
rules-dev mailing list
rules-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-dev