[rules-users] xdrl, matches and nested method calls

[Wolfgang Laun]

It seems that string escape processing by the Drools compiler and builder
either handles the control character escapes such as \t or \n, *or* the
pattern escapes \Q, \E, etc.

By default, control character escapes are handled correctly, but any '\'
not in front of rftnb'"\ is simply dropped.

To get the regex backslash escapes, you'll have to write them Java-style,
e.g. \\Q, \\E.

If you don't intend to use the aforementioned control escapes. you can do
    KnowledgeBuilderConfiguration kbConfig =
KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration();
    kbConfig.setOption(  ProcessStringEscapesOption.NO; );
    KnowledgeBuilder kBuilder =
KnowledgeBuilderFactory.newKnowledgeBuilder( kbConfig );
and then you can write the regexp's with a single '\', i.e.,
".*\QCRYPT\W.*". (This is documented
as reverting to Drools 4 behaviour.)

This contradicts the documentation, so I think it is a bug; but I
don't really know what
the intended behaviour with and without that builder option is.
Anyway, it contradicts
what is said in Expert, next to the "matches" operator. The javadoc of
ProcessStringEscapesOption
isn't mentioning regexp escapes.

@Edson: I think  it can be fixed easily in
org.drools.core.util.StringUtils; just emit the '\' if it isn't
followed by one of  rftnb'"\ .in line 915.

-W


On 21 October 2010 11:10, Veit Guna <veit.guna at gmx.de> wrote:
> Indeed. It returns "my CRYPT subject". Added a system out to its get method.
>
> The funny thing is, tried it with
>
> value=".*CRYPT.*"
>
> and
>
> field-name="subject"
>
> and it matches.
>
> I don't get it.
>
>
>
> Am 21.10.2010 11:02, schrieb Wolfgang Laun:
>> Unlikely... but do check the getSubject() method - does it return the
>> correct value?
>> -W
>>
>> On 21 October 2010 10:52, Veit Guna <veit.guna at gmx.de> wrote:
>>> Hi.
>>>
>>> We're using Drools 5.1.0 with .xdrl files. Now we encountered a strange
>>> problem with the 'matches' behavior.
>>>
>>> We have the following pattern that seems to have the problem:
>>>
>>> <dro:pattern object-type="EMail">
>>>  <dro:field-constraint field-name="subject">
>>>    <dro:literal-restriction evaluator="matches" value=".*\QCRYPT\E.*"/>
>>>  </dro:field-constraint>
>>> </dro:pattern>
>>>
>>> Subject is a String with the content "my CRYPT subject".
>>>
>>> The rule isn't fired as expected. If we ONLY change
>>>
>>> field-name="subject"
>>>
>>> to
>>>
>>> field-name="subject.trim"
>>>
>>> the rule fires.
>>>
>>> Any pointers what that is?
>>>
>>> Thanks
>>> Veit
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>>
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>