<br> Looks like a bug on the type enforcement that Drools and MVEL try to apply. Even with the generic type erasure, there should be no problems with either expression. <br><br> What specific versions of Drools and MVEL are you using?<br>
<br> Edson<br><br><br><div class="gmail_quote">2010/1/31 <span dir="ltr"><<a href="mailto:rouvas@di.uoa.gr">rouvas@di.uoa.gr</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Wolfgang Laun wrote:<br>
> 2010/1/31 <<a href="mailto:rouvas@di.uoa.gr">rouvas@di.uoa.gr</a>><br>
><br>
>> Wolfang,<br>
>><br>
>> thank you very much for your reply.<br>
>><br>
>> Your assumptions are correct and your explanation makes sense.<br>
>> Unfortunately, I cannot understand why this happens.<br>
>><br>
>><br>
> It may very well be an implementation restriction; whether it can be<br>
> removed easily I'm not prepared to say. (@Edson?)<br>
<br>
</div>Fair enough.<br>
<div class="im"><br>
><br>
><br>
>> The IUEcop has the following structure (in rough terms)<br>
>> IUEcop<br>
>> +- (various objects as properties)<br>
>> +- list of traderAuthorisation<br>
>> +- list of warehouseAuthorisation<br>
>> +- list of temporaryAuthorisation<br>
>><br>
>><br>
>> A more general issue with my understanding has to do with handling of<br>
>> deeply nested objects. In my case, the "traderAuthorisation" object has<br>
>> itself another set of object properties and lists that I would like to<br>
>> refer to in my rules. Are you aware of any relevant documentation?<br>
>><br>
><br>
> Nested objects that are not facts but shared between fact objects should<br>
> not<br>
> cause any problems; especially the MVEL syntax is provided for easy<br>
> access to properties of a property.<br>
><br>
> If such an object is shared among several fact objects, you'll have a<br>
> problem whenever such a shared object is updated by code on a RHS:<br>
> To trigger reevaluation of rules, the engine would have to be<br>
> notified about all objects referring to the shared object as being<br>
> updated.<br>
<br>
</div>Although in my case the objects are not shared, I understand the issues<br>
involved.<br>
<div class="im"><br>
><br>
> Lists is adding another twist, even though the "from" CE appears<br>
> to simplify handling of Iterable properties and works well enough.<br>
> The recommended (see Drools Expert, section 4.8.2.8, Conditional<br>
> Element "from") alternative is to add List elements as WM elements<br>
> of their own,<br>
<br>
</div>I was hoping to avoid this.<br>
This is how I was doing things in Prolog, but I was hoping that<br>
object-orientation would help tackling this issue.<br>
<br>
Anyway, thanks a lot for your help.<br>
<br>
-Stathis<br>
<div class="im"><br>
> even though this may require the addition of linking<br>
> information to the list elements. (In your case: a TraderAuthorisation<br>
> would have to contain a reference to the IUEcop object it belongs<br>
> to.) You'll have to balance the additionally required coding effort<br>
> for this against the greater complexity of rules using "from".<br>
><br>
> -W<br>
><br>
><br>
>> Thank you very much for your time,<br>
>> -Stathis<br>
>><br></div></blockquote></div><br clear="all"><br>-- <br> Edson Tirelli<br> JBoss Drools Core Development<br> JBoss by Red Hat @ <a href="http://www.jboss.com">www.jboss.com</a><br>