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 <[email protected]> > >> Wolfgang Laun wrote: >> > 2010/1/31 <[email protected]> >> > >> >> 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
