Re: [rules-users] ClassCastException when comparing date type with literal

On 31/03/2012, Zeke <xanadu860122(a)gmail.com&gt; wrote: > It is just a test case used to bring up the issue. The real rule condition > in my business logic is more complex, like > Order( id == '...', $msg.date > '...', num == $msg.num ). Of course I can > change to use Message as Pattern to work aournd, but it is too tricky, > right? And no matter the usage is weird or not, it is legal, right? > I can't really say what was legal in 4.0.7, but $msg: Message() Order( $msg.date > '...' ) was not legal in 5.1.1. For any constraint, the left hand side would have to be a reference to a field of the fact where it occurs. Order(Id == '...') # is OK You can refer to fields of another fact on the RHS: Order(num == $msg.num ) # is OK Any other expression would have to be written in clean Java (or MVEL) but enclosed in eval() Order( eval( $msg.getDate().compareTo( new Date(...) ) == 1 ) ) # or similar ;-) Starting with 5.2.0, this restriction was mitigated and by 5.3.0 and certainly in 5.4.0 a wide range of (boolean) expressions is acceptable. However, I should emphasize that postponing the use of a constraint into a later pattern is an antipattern for rule coding. Consider $msg: Message() This matches any fact of type Message, and the Engine must needs keep track of this. Contrariwise, $msg: Message( date > "...") narrows this effort down. Putting a constraint where it belongs is not a "workaround", it's best practice :) -W > I am using Drools 4.0.7. If later release fixes this bug, I may try to > upgrade. I don't want to change LHS. It will bring much effort in my > project. > > > On 30 March 2012 14:09, FrankVhh <frank.vanhoenshoven(a)agserv.eu&gt; wrote: > >> Let me rephrase my question: >> >> As date is an attribute of message, why don't you use: >> >> $msg : Message( date > "...") >> >> Constraining an attribute of Message in the Order pattern seems a weird >> thing to do. >> >> >> >> Zeke-3 wrote >> > >> > It seems not work. >> > When I try >> > *$msg : Message($date : date) >> > Order ( $date > "Mar-01-2012" )* >> > I meet error "Unable to create Field Extractor for '$date' of >> > '[ClassObjectType class=org.drools.examples.HelloWorldExample$Second]' >> > in >> > rule 'default' : [Rule name=default, agendaGroup=MAIN, salience=0, >> > no-loop=false]" >> > >> > When I try >> > *$msg : Message($date : date) >> > eval ( $date > "Mar-01-2012" )* >> > If the dialect is "java", I meet error "Rule Compilation error : [Rule >> > name=default, agendaGroup=MAIN, salience=0, no-loop=false] >> > org/drools/examples/test/Rule_default_0.java (8:354) : The operator >> > > >> > is undefined for the argument type(s) Date, String" >> > If the dialect is "mvel", I meet the same ClassCastException. >> > >> > On 29 March 2012 22:28, FrankVhh &lt;frank.vanhoenshoven@&gt; wrote: >> > >> >> This may sound a bit rude, but... why would you want to do such a >> >> thing? >> >> >> >> If there is a constraint on the message, then why not put that >> constraint >> >> in >> >> the message structure? >> >> >> >> Btw, I think it would work by using eval($date < "...") but see no use >> >> for >> >> it either. >> >> >> >> >> >> Joe Zendle wrote >> >> > >> >> > did you try: >> >> > >> >> > *$msg : Message($date : date) >> >> > Order ( $date > "Mar-01-2012" )* >> >> > >> >> > >> >> > >> >> > 2012/3/29 Zeke &lt;xanadu860122@&gt; >> >> > >> >> >> Hi, guys: >> >> >> I meet a strange issue and need your help again... I am using >> Drools >> >> >> 4.0.7. >> >> >> When my rule condition is as *Message( date > "Mar-01-2012" )*, >> >> >> everything is OK. But if I change it to be as below: >> >> >> *$msg : Message() >> >> >> Order ( $msg.date > "Mar-01-2012" )* >> >> >> I will meet "java.lang.String cannot be cast to java.util.Date" >> >> >> ClassCastException. "Order" is another fact. I attach the exception >> >> call >> >> >> stack. Please check it. It looks like a bug to me. Do we fix it in >> >> later >> >> >> release? If so, can you tell me which release contains the fix? >> >> Thanks! >> >> >> >> >> >> _______________________________________________ >> >> >> rules-users mailing list >> >> >> rules-users@.jboss >> >> >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> >> >> >> >> > >> >> > _______________________________________________ >> >> > rules-users mailing list >> >> > rules-users@.jboss >> >> > https://lists.jboss.org/mailman/listinfo/rules-users >> >> > >> >> >> >> >> >> -- >> >> View this message in context: >> >> >> http://drools.46999.n3.nabble.com/rules-users-ClassCastException-when-com... >> >> Sent from the Drools: User forum mailing list archive at Nabble.com. >> >> _______________________________________________ >> >> rules-users mailing list >> >> rules-users@.jboss >> >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> > >> > _______________________________________________ >> > rules-users mailing list >> > rules-users@.jboss >> > https://lists.jboss.org/mailman/listinfo/rules-users >> > >> >> >> -- >> View this message in context: >> http://drools.46999.n3.nabble.com/rules-users-ClassCastException-when-com... >> Sent from the Drools: User forum mailing list archive at Nabble.com. >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users