[rules-users] [BAD Bug] incorrect evaluation of LHS using Integer/Number intValue
Wolfgang Laun
wolfgang.laun at gmail.com
Mon Jan 21 01:38:37 EST 2013
Since you didn't answer my question, you've answered it indeed :-\
So I just have to assume that not and exist CEs using constraints
employing the four comparison operators /[<>]=?/ are not safe in
5.5.0. - Would it be correct to post this as a concluding remark to
the OPs question? I don't want to paint it too black, you know.
-W
On 21/01/2013, Mark Proctor <mproctor at codehaus.org> wrote:
> We will be releasing 5.6 soon.
>
> Mark
> On 20 Jan 2013, at 17:26, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>
>> Isn't this bug hefty enough to render 5.5.0 unusable?
>> -W
>>
>> On 20/01/2013, Mark Proctor <mproctor at codehaus.org> wrote:
>>> We tracked it down to the range indexing iterator, in not and exist
>>> nodes.
>>> Should be fixed next week.
>>>
>>> Mark
>>>
>>>
>>> On 20 Jan 2013, at 08:23, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>>>
>>>> Below is another couple of test cases, showing that the problem is not
>>>> due
>>>> a getter that isn't called get* - it's a more general problem. As far
>>>> as
>>>> I
>>>> can tell this rule pattern, expecting to fire in ascending order of
>>>> Fact.prop, is broken in 5.5.0:
>>>>
>>>> rule "Rule xx"
>>>> when
>>>> $fact: Fact( $prop: prop )
>>>> not Fact(prop < $prop)
>>>> then
>>>> System.out.println("Fact.prop: " + $prop);
>>>> retract($fact);
>>>> end
>>>>
>>>> // Test case using String
>>>>
>>>> rule init
>>>> salience 9999
>>>> when
>>>> then
>>>> insert( "AAA" );
>>>> insert( "DDD" );
>>>> insert( "EEE" );
>>>> insert( "CCC" );
>>>> insert( "BBB" );
>>>> end
>>>>
>>>> rule "Rule 05"
>>>> when
>>>> $s : String()
>>>> not String( this < $s)
>>>> then
>>>> System.out.println("String found with value: " + $s );
>>>> retract($s);
>>>> end
>>>>
>>>> // Test case using declared type
>>>> declare Fact
>>>> prop : long
>>>> end
>>>>
>>>> rule init
>>>> salience 999
>>>> when
>>>> then
>>>> insert( new Fact( 1 ) );
>>>> insert( new Fact( 5 ) );
>>>> insert( new Fact( 6 ) );
>>>> insert( new Fact( 4 ) );
>>>> insert( new Fact( 2 ) );
>>>> end
>>>>
>>>> rule "Rule 06"
>>>> salience 100
>>>> when
>>>> $fact : Fact( $prop: prop )
>>>> not Fact( prop < $prop )
>>>> then
>>>> System.out.println("Fact.prop: " + $prop);
>>>> retract($fact);
>>>> end
>>>>
>>>> On 20/01/2013, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>>>>> [Sorry - the previous email "escaped" before I was complete.]
>>>>>
>>>>> This is a self-contained DRL demonstrating the erroneous handling of
>>>>> a condition involving Integer.intValue (same: Number.intValue), not
>>>>> and retract, which is meant to sort the integers. This fails with
>>>>> 5.5.0,
>>>>> but works correctly with 5.4.0 and previous versions.
>>>>>
>>>>> rule init
>>>>> salience 9999
>>>>> when
>>>>> then
>>>>> insert( Integer.valueOf( 10 ) );
>>>>> insert( Integer.valueOf( 50 ) );
>>>>> insert( Integer.valueOf( 60 ) );
>>>>> insert( Integer.valueOf( 40 ) );
>>>>> insert( Integer.valueOf( 20 ) );
>>>>> end
>>>>>
>>>>> rule "Rule 04"
>>>>> when
>>>>> $number : Integer( $i: intValue )
>>>>> not Integer(intValue < $i)
>>>>> then
>>>>> System.out.println("Number found with value: " +
>>>>> $number.intValue());
>>>>> retract($number);
>>>>> end
>>>>>
>>>>>>
>>>>>> On 17/01/2013, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:
>>>>>>> This BAD bug was introduced on the way from 5.4.0 to 5.5.0 (and
>>>>>>> seems
>>>>>>> to have sneaked into 6.0.0 as well).
>>>>>>>
>>>>>>> Only 5.4.0 and predecessors work as expected.
>>>>>>>
>>>>>>> Damage control? How far can 5.5.0 be trusted?
>>>>>>>
>>>>>>>
>>>>>>> On 17/01/2013, John Smith <ffirstt.llastt at gmail.com> wrote:
>>>>>>>> I am new to Drools and am trying to get the sample program to work.
>>>>>>>> This
>>>>>>>> sample is given in the drools documentation
>>>>>>>> http://docs.jboss.org/drools/release/5.5.0.Final/drools-expert-docs/html_single/index.html#d0e9542.
>>>>>>>> This drool rule is expected to sort integers. I just changed the
>>>>>>>> numbers
>>>>>>>> from what are given in the sample and they do not get sorted as
>>>>>>>> expected.
>>>>>>>> Tried using drools version 5.5.0, 5.5.1 and the master 6.0.0, but
>>>>>>>> got
>>>>>>>> the
>>>>>>>> same wrong results.
>>>>>>>>
>>>>>>>> Following is the main code:
>>>>>>>> package com.sample;
>>>>>>>>
>>>>>>>> public class Example2 {
>>>>>>>> public static void main(String[] args) throws Exception {
>>>>>>>> Number[] numbers = new Number[] { wrap(5), wrap(6), wrap(4),
>>>>>>>> wrap(1), wrap(2) };
>>>>>>>> new RuleRunner().runRules(new String[] { "Example3.drl" },
>>>>>>>> numbers);
>>>>>>>> }
>>>>>>>>
>>>>>>>> private static Integer wrap(int i) {
>>>>>>>> return new Integer(i);
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> The RuleRunner class is the same as given in the example and I do
>>>>>>>> not
>>>>>>>> think
>>>>>>>> I should give that here, since it will clutter the question. It
>>>>>>>> simply
>>>>>>>> creates the KnowledgeBase, stateful session, inserts the facts as
>>>>>>>> given
>>>>>>>> in
>>>>>>>> the 'numbers' array above and then calls fireAllRules method on the
>>>>>>>> session.
>>>>>>>>
>>>>>>>> The rule file (Example3.drl) is:
>>>>>>>>
>>>>>>>>
>>>>>>>> rule "Rule 04"
>>>>>>>> dialect "mvel"
>>>>>>>> when
>>>>>>>> $number : Number()
>>>>>>>> not Number(intValue < $number.intValue)
>>>>>>>> then
>>>>>>>> System.out.println("Number found with value: " +
>>>>>>>> $number.intValue());
>>>>>>>> retract($number);
>>>>>>>> end
>>>>>>>>
>>>>>>>>
>>>>>>>> The output I get is as follows:
>>>>>>>> Loading file: Example3.drl
>>>>>>>> Inserting fact: 5
>>>>>>>> Inserting fact: 6
>>>>>>>> Inserting fact: 4
>>>>>>>> Inserting fact: 1
>>>>>>>> Inserting fact: 2
>>>>>>>> Number found with value: 1
>>>>>>>> Number found with value: 4
>>>>>>>> Number found with value: 2
>>>>>>>> Number found with value: 5
>>>>>>>> Number found with value: 6
>>>>>>>>
>>>>>>>> Not the correct expected ascending sorted order.
>>>>>>>>
>>>>>>>> What might I be doing wrong? I cannot imagine that the drools rule
>>>>>>>> engine
>>>>>>>> would be broken at this basic level.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>> http://drools.46999.n3.nabble.com/Drools-Expert-does-not-sort-integers-correctly-tp4021606.html
>>>>>>>> Sent from the Drools: User forum mailing list archive at
>>>>>>>> Nabble.com.
>>>>>>>> _______________________________________________
>>>>>>>> rules-users mailing list
>>>>>>>> rules-users at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> rules-users mailing list
>>>> rules-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
More information about the rules-users
mailing list