[rules-users] Drools Bug: Custom Operator with Maps results in Mvel Error

[Edson Tirelli]

   Uday,

   The short answer is: Drools supports pluggable evaluators only for
direct fact attributes, with direct values as a second parameter. It
is not possible to use nested access or map access when using
pluggable operators. The workaround for now is to extract the value
from the map before using your operator.

MyValue( myField myoperator xxx ) from $myMap["someKey"]

    The long answer is: Drools process all direct attributes by
himself, and delegates any nested access and map/collection access to
MVEL. This is just a quick solution to avoid forcing users to wrap
nested property access in eval() blocks. The problem with that is that
it causes inconsistencies like this, between what drools processes
natively and what it delegates to MVEL.

    As I mentioned in my previous e-mail, we had a team meeting last
week and defined solving these inconsistencies in corner cases as one
of our top goals for the next version of Drools. The idea is to
eliminate these differences by always delegating constraint resolution
to MVEL, while adding support in MVEL for any non-existing feature,
like pluggable operators. Also, we want to add support to free form
expressions in constraints, eliminating the requirement to have a
field access on the left, operator in the center and value or
parenthesized expression on the right, etc.

    Hope this helps,
        Edson

2010/10/28 Uday Kodukula <ukodukula at synacor.com>:
>
> Hello,
>
> I'm not sure if this is a bug, but I'd like to check with the Drools experts
> to see if it is.
>
> I noticed this when creating my custom operator, which doesn't appear to
> recognize values from Maps, but works fine with non Map based values.
>
> I have created a custom comparison operator which takes in a parameter to
> determine how to execute the comparison logic.
>
> So for example, I am able to do the following:
>
>      id udaycompare[gt] 1
>
> where id is an integer. So for the sake of clarity this is equivalent to "id
>> 1".
>
> Now, when I try to extract an integer from a HashMap called myMap, who has
> an integer value for the key "someKey", I get an error raised by MVEL:
>
>      myMap["someKey"] udaycompare[gt] 1
>
> Error thrown:
>
> Unable to determine the used declarations.
> [Error: unknown class or illegal statement: org.mvel2.ParserContext at 1d87b85]
> [Near : {... myMap["someKey"] udaycompare  ....}]
>                                                                ^
> It appears that Mvel doesn't like getting values from HashMap when working
> with custom operators. I also tried an alternate way of getting that key
> from the map as follows:
>
>      myMap.someKey udaycompare[gt] 1
>
> but i still get the same error.
>
> Any thoughts would be greatly appreciated.
>
> Thanks,
> Uday
> --
> View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Bug-Custom-Operator-with-Maps-results-in-Mvel-Error-tp1790252p1790252.html
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>



-- 
  Edson Tirelli
  JBoss Drools Core Development
  JBoss by Red Hat @ www.jboss.com