6:30 a.m.
Wolfgang Laun wrote:
2010/1/31 <rouvas(a)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
>
>
9:24 a.m.
New subject: newbie, Expressing a rule in different ways
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?
Edson
2010/1/31 <rouvas(a)di.uoa.gr>
Wolfgang Laun wrote:
> 2010/1/31 <rouvas(a)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
5:27 p.m.
New subject: newbie, Expressing a rule in different ways
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(a)di.uoa.gr>
> Wolfgang Laun wrote:
> > 2010/1/31 <rouvas(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5413
days inactive
5413
days old
2 comments
2 participants
participants (2)
-
Edson Tirelli -
rouvas＠di.uoa.gr