where the parser is o.a.j.core.query.lucene.fulltext.QueryParser. It seems to break on string ending with a "!". Unfortunately, I do not have insight in how the QueryParser works. Perhaps somebody else knows where to look in the QueryParser .

Ard Schrijvers
added a comment - 30/Nov/07 09:26 Repeated from user-list:
It seems that in LuceneQueryBuilder at
Object visit(TextsearchQueryNode node, Object data) {
it breaks at
Query context = parser.parse(query.toString());
where the parser is o.a.j.core.query.lucene.fulltext.QueryParser. It seems to break on string ending with a "!". Unfortunately, I do not have insight in how the QueryParser works. Perhaps somebody else knows where to look in the QueryParser .

In addition to the already specified set of special character in JSR 170, Jackrabbit uses more of those characters for extended functionality.

This set of characters should be limited to the ones really required (e.g. ! is equivalent to -) and clearly documented. It would be nice to also have a utility class that automatically escapes the special characters used in Jackrabbit.

Marcel Reutegger
added a comment - 30/Nov/07 14:30 In addition to the already specified set of special character in JSR 170, Jackrabbit uses more of those characters for extended functionality.
This set of characters should be limited to the ones really required (e.g. ! is equivalent to -) and clearly documented. It would be nice to also have a utility class that automatically escapes the special characters used in Jackrabbit.

Jukka Zitting
added a comment - 20/Oct/08 22:03 This turned out to be implemented as a new feature in jcr-commons, changing issue metadata accordingly.
I guess the original problem (ParseException) is the expected (though undocumented) behavior, so there's no need to fix this for clients that don't use the new helper method.

Specification JSR-170 at point 6.6.5.2 says that literal instances like single quote ( ' ), double quote ( " ) and hyphen ( - ) must be escaped with a backslash ( \ ), and backslash itself should be escaped as a double backslash ( ). Also, I have noted that some chars like [ and ] need to be escaped also.

Paco Avila
added a comment - 01/Mar/10 19:36 - edited A query like this will fail:
//element(*, nt:base) [jcr:contains(., 'test \ done')]
Specification JSR-170 at point 6.6.5.2 says that literal instances like single quote ( ' ), double quote ( " ) and hyphen ( - ) must be escaped with a backslash ( \ ), and backslash itself should be escaped as a double backslash ( ). Also, I have noted that some chars like [ and ] need to be escaped also.

Alexander Klimetschek
added a comment - 01/Mar/10 21:36 > A query like this will fail:
> //element(*, nt:base) [jcr:contains(., 'test \ done')]
Did you use org.apache.jackrabbit.util.Text.escapeIllegalXpathSearchChars() ? In case that one has a bug, please file a new issue.
See also http://wiki.apache.org/jackrabbit/EncodingAndEscaping

Paco Avila
added a comment - 02/Mar/10 09:12 I'm not sure if is a bug or a "feature". The query
String term = "pe[]pe";
String scapedTerm = Text.escapeIllegalXpathSearchChars(term).replaceAll("'", "''")
String query = "/jcr:root//* [jcr:contains(okm:content,'"+escapedTerm+"')] "
should fail or the term "pe[]pe" should be escaped as "pe[]pe"?