You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Ard Schrijvers (JIRA)" <ji...@apache.org> on 2008/01/03 17:59:34 UTC
[jira] Commented: (JCR-1288) query parser doesn't handle relative
XPath expressions
[ https://issues.apache.org/jira/browse/JCR-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555609#action_12555609 ]
Ard Schrijvers commented on JCR-1288:
-------------------------------------
Are you sure (1) and (3) are treated similar?
If for example in LimitAndOffsetTest I test with the query
1) query = createXPathQuery("testroot/*");
2) query = createXPathQuery("testroot/foo");
3) query = createXPathQuery("/jcr:root/testroot/*");
4) query = createXPathQuery("/jcr:root/testroot/foo");
5) query = createXPathQuery("/testroot/*");
6) query = createXPathQuery("/testroot/foo");
then (1) , (2) , (3) and (4) work and (5) and (6) breaks.
Are you trying with the trunk?
> query parser doesn't handle relative XPath expressions
> ------------------------------------------------------
>
> Key: JCR-1288
> URL: https://issues.apache.org/jira/browse/JCR-1288
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Reporter: Julian Reschke
> Priority: Minor
>
> JSR-170 says that relative query (XPATH) expression are evaluated against "/jcr:root", thus
> (1) a/b
> and
> (2) /jcr:root/a/b
> would be equivalent, while
> (3) /a/b
> means something else (will never match anything). Unfortunately, the query parser seems to treat (1) and (3) the same way, which makes it hard to disnguish the two cases.
> (this probably means that Jackrabbit accepts a class of broken queries (3) that it shouldn't accept)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.