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 <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/rules-users >>>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >> _______________________________________________ >> rules-users mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
