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

[Veit Guna]

Hi.

Thanks for the detailed explanation!

Confirmed that both ways you mention do the trick. I'll stick with
ProcessStringEscapesOption.NO for now.

Thanks
Veit


Am 21.10.2010 14:07, schrieb 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
>>
> 
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>