[
https://issues.apache.org/jira/browse/JCR-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485448
]
Marcel Reutegger commented on JCR-789:
--------------------------------------
Julian Reschke (JIRA) wrote:
> Unless it's used somewhere where relative paths are matched (such as in
> Node.getnNodes(relpath)).
relative paths have the same restrictions and rules like absolute paths. The
method you mention does not take a relative path argument but a name pattern
and those never have an index.
Tobias wrote:
> - use a 0-based index (when storing as int) throughout the code (also in
> NodeState)
What's the benefit of using a 0-based index when the spec says they are
1-based? Wouldn't that make the implementation more complicated to understand?
IMO the INDEX_UNDEFINED only makes sense in context of an XPath query. If a
path element does not have an index in XPath then all same named nodes are
selected regardless of what index they have. Whereas in the JCR API
Node.getNode("foo") and Node.getNode("foo[1]") is the same.
I think the crucial question is: does the spec says anywhere an 1-index needs
to preserved in a path?
> PathElement.equals doesn't handle INDEX_UNDEFINED
> -------------------------------------------------
>
> Key: JCR-789
> URL: https://issues.apache.org/jira/browse/JCR-789
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Reporter: Julian Reschke
> Priority: Minor
> Attachments: jcr789.diff.txt
>
>
> PathElement (and therefore Path) comparisons fail when INDEX_UNDEFINED is
> used (it's treated differently from INDEX_DEFAULT).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
