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.