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

Wolfgang Laun wolfgang.laun at gmail.com
Sat Mar 31 01:06:10 EDT 2012


On 31/03/2012, Zeke <xanadu860122 at gmail.com> 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 at agserv.eu> 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 at .jboss
>> >> >> https://lists.jboss.org/mailman/listinfo/rules-users
>> >> >>
>> >> >>
>> >> >
>> >> > _______________________________________________
>> >> > rules-users mailing list
>> >> > rules-users at .jboss
>> >> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >> >
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >>
>> http://drools.46999.n3.nabble.com/rules-users-ClassCastException-when-comparing-date-type-with-literal-tp3867229p3867832.html
>> >> Sent from the Drools: User forum mailing list archive at Nabble.com.
>> >> _______________________________________________
>> >> rules-users mailing list
>> >> rules-users at .jboss
>> >> https://lists.jboss.org/mailman/listinfo/rules-users
>> >>
>> >
>> > _______________________________________________
>> > rules-users mailing list
>> > rules-users at .jboss
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>>
>>
>> --
>> View this message in context:
>> http://drools.46999.n3.nabble.com/rules-users-ClassCastException-when-comparing-date-type-with-literal-tp3867229p3870029.html
>> Sent from the Drools: User forum mailing list archive at Nabble.com.
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>



More information about the rules-users mailing list