[rules-dev] Cloning Collections issue

Wolfgang Laun wolfgang.laun at gmail.com
Sat May 28 04:26:35 EDT 2011


There is only one object of class ArrayList<Cheese>. Bound to $cheeseList is
the "live" list used in the rete machinery, and this reference is stored in
the global "results" (List<ArrayList<Cheese>>, at 0). Due to more cheese
being put on the table, the list fattens (small wonder!), and Java code
"sees" the growing list.

The second set of assertions was updated by Mark to use 3 for the size of
the list, and *does not fail now.*

-W


On 27 May 2011 22:47, Michael Anstis <michael.anstis at gmail.com> wrote:

> Where does it now fail?
>
> I'd assume the first part of the test (where only 1 Cheese exists) would
> still pass, but the second part of the test where 3 Cheeses existing in
> total to now fail.
>
> Is my understanding correct?
>
> Cheers,
>
> Mike
>
> On 26 May 2011 05:44, Mark Proctor <mproctor at codehaus.org> wrote:
>
>>  https://issues.jboss.org/browse/JBRULES-3051
>>
>> Previously ALL collections where cloned when bound:
>>
>> public Object getNonShadowedValue(InternalWorkingMemory workingMemory,
>>                                       final Object object) {
>>         Object result = this.readAccessor.getValue( workingMemory,
>>                                                     object );
>>         if ( this.isInternalFact() && result instanceof Collection ) {
>>             try {
>>                 Collection newCol = (Collection) result.getClass().newInstance();
>>                 for ( Iterator it = ((Collection) result).iterator(); it.hasNext(); ) {
>>                     Object element = it.next();
>>                     newCol.add( element );
>>                 }
>>                 return newCol;
>>             } catch ( InstantiationException e ) {
>>                 // nothing we can do, so just return the resulting object            } catch ( IllegalAccessException e ) {
>>                 // TODO Auto-generated catch block            }
>>         }
>>         return result;
>>     }
>>
>>  This was left over from shadow facts and actually still existed today. I
>> have removed the code but now we have a failing test in
>> FirstOrderLogicTest.testCollectResultConstraints.
>>
>> rule "Collect Test" salience 70
>>     when
>>         $cheeseList  : ArrayList(size == 1) from collect( Cheese( ) );
>>     then
>>         results.add($cheeseList);
>> end
>>
>>  The reason why this passed before was the collection was cloned, so the
>> accumulate's evaulations would not impact it. Now it is no longer cloned and
>> while the rule does not fire the Collection is updated. I think the later is
>> the correct behaviour and I've updated the test as expected. Everyone
>> agreed?
>>
>>
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110528/c7c06c27/attachment.html 


More information about the rules-dev mailing list