[rules-users] newbie, Expressing a rule in different ways

[rouvas at di.uoa.gr]

Edson Tirelli wrote:
>    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.
>
>    What specific versions of Drools and MVEL are you using?

I am using Drools.5.0.
I do not know the specific versions of the JARs, but here is the list of
JARs I am using:

./lib
./lib/commons-io-1.4.jar
./lib/janino-2.5.15.jar
./lib/jxls-reader-0.9.6.jar
./lib/jettison-1.0.1.jar
./lib/joda-time-1.6.jar
./lib/commons-net-2.0.jar
./lib/jsr94-1.1.jar
./lib/mail-1.4.jar
./lib/xstream-1.3.1.jar
./lib/slf4j-jdk14-1.5.2.jar
./lib/javassist-3.4.GA.jar
./lib/jxl-2.4.2.jar
./lib/jta-1.0.1B.jar
./lib/stax-1.2.0.jar
./lib/commons-collections-3.2.jar
./lib/activemq-core-5.2.0.jar
./lib/rome-0.9.jar
./lib/persistence-api-1.0.jar
./lib/h2-1.0.77.jar
./lib/simple-jndi-0.11.4.jar
./lib/dom4j-1.6.1.jar
./lib/commons-exec-1.0.0-20080905.033237-1.jar
./lib/jboss-vfs-2.0.0.GA.jar
./lib/milyn-smooks-javabean-1.1.jar
./lib/jboss-seam-2.1.1.GA.jar
./lib/hibernate-core-3.3.0.SP1.jar
./lib/ant-nodeps-1.6.5.jar
./lib/commons-finder-1.0-20080905.033643-1.jar
./lib/hibernate-commons-annotations-3.1.0.GA.jar
./lib/jaxb-impl-2.0.3.jar
./lib/core-3.4.2.v_883_R34x.jar
./lib/antlr-runtime-3.1.1.jar
./lib/jaxb-xjc-2.0.3.jar
./lib/smack-3.0.4.jar
./lib/commons-compress-1.0-20080905.032625-1.jar
./lib/slf4j-api-1.5.2.jar
./lib/slf4j-api-1.5.6.jar
./lib/hibernate-entitymanager-3.4.0.GA.jar
./lib/mina-core-2.0.0-M3.jar
./lib/mvel2-2.0.10.jar
./lib/hibernate-annotations-3.4.0.GA.jar
./lib/ant-1.6.5.jar
./lib/activation-1.1.jar
./drools-jsr94-5.0.1.jar
./drools-verifier-5.0.1.jar
./drools-transformer-jaxb-5.0.1.jar
./LICENSE-ASL-2.0.txt
./drools-api-5.0.1.jar
./drools-workitems-5.0.1.jar
./drools-mc-5.0.1.jar
./drools-bam-5.0.1.jar
./drools-transformer-jxls-5.0.1.jar
./drools-messenger-jms-5.0.1.jar
./README_DEPENDENCIES.txt
./drools-ant-5.0.1.jar
./drools-decisiontables-5.0.1.jar
./drools-persistence-jpa-5.0.1.jar
./drools-process-task-5.0.1.jar
./drools-compiler-5.0.1.jar
./drools-clips-5.0.1.jar
./drools-server-5.0.1.war
./drools-transformer-smooks-5.0.1.jar
./drools-transformer-xstream-5.0.1.jar
./drools-templates-5.0.1.jar
./drools-core-5.0.1.jar

Thank you very much for your time,
-Stathis

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