[
https://issues.apache.org/jira/browse/OAK-5260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15748605#comment-15748605
] Thomas Mueller edited comment on OAK-5260 at 12/14/16 3:27 PM: --------------------------------------------------------------- [~bdelacretaz] JavaCC would be (a) tricky due to the "Listener" callback mechanism, (b) probably result in slower code, and (c) be harder to maintain. I have used both [ANTLR|http://newsql.sourceforge.net/] and JavaCC in the past, but I find hand-written parsers [1|https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/command/Parser.java] [2|https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/jdbc/JdbcConnection.java#L1291] [3|http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/query/sql2/Parser.java] [4|http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/SQL2Parser.java] [5|http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/xpath/XPathToSQL2Converter.java] [6|http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/json/JsopTokenizer.java] [7| https://github.com/h2database/h2database/blob/master/h2/src/tools/org/h2/build/doc/XMLParser.java] [8|https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/bnf/Bnf.java#L86] to be easier to write and maintain and faster. was (Author: tmueller): [~bdelacretaz] JavaCC would be (a) tricky due to the "Listener" callback mechanism, (b) probably result in slower code, and (c) be harder to maintain. I have used both ANTLR [9] and JavaCC in the past, but I find hand-written parsers [1]-[8] to be easier to write and maintain. [1] https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/command/Parser.java [2] https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/jdbc/JdbcConnection.java#L1291 [3] http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-jcr-commons/src/main/java/org/apache/jackrabbit/commons/query/sql2/Parser.java [4] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/SQL2Parser.java [5] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/query/xpath/XPathToSQL2Converter.java [6] http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-commons/src/main/java/org/apache/jackrabbit/oak/commons/json/JsopTokenizer.java [7] https://github.com/h2database/h2database/blob/master/h2/src/tools/org/h2/build/doc/XMLParser.java [8] https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/bnf/Bnf.java#L86 [9] http://newsql.sourceforge.net/ > Incorrect handling of subpaths with leading left curly bracket > -------------------------------------------------------------- > > Key: OAK-5260 > URL: https://issues.apache.org/jira/browse/OAK-5260 > Project: Jackrabbit Oak > Issue Type: Bug > Components: jcr > Reporter: Bertrand Delacretaz > Assignee: Julian Sedding > Fix For: 1.6 > > Attachments: OAK-5260-jsedding.patch, OAK-5260.patch > > > As per SLING-6383 it looks like the Oak name mapping causes for example > getItem("/libs/{sub") (with a left curly bracket in the path) to return the > /libs node if that exists but the supplied path does not. > I'll attach a patch with a test that demonstrates this. > [~fmeschbe] mentions in that Sling issue that the parsing of the CR 2 section > 3.2.5.1 Expanded Form could be involved, treating the left curly bracket in a > special way that's not appropriate here. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
