[
https://issues.apache.org/jira/browse/JCR-789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485342
]
Julian Reschke commented on JCR-789:
------------------------------------
> BTW, is there even a need for the INDEX_UNDEFINED case? In other words, could
> we always normalize path components to internally always have an index that
> is >= 1? If the index is 1, then the "[n]" part would be skipped during
> string serialization.
Unless it's used somewhere where relative paths are matched (such as in
Node.getnNodes(relpath)).
> Another note about this issue, does the comparison failure cause a regression
> against documented behaviour? If not, then I'd categorize this as an
> improvement rather than a bug.
I think it *did* cause a failure for me in JCR2SPI, until I adjusted my SPI
implementation so that Path objects were built exactly the way expected by
JCR2SPI (because that one is using Path.equals to compare paths).
To summarize: we either should change .equals(), or, if we can't, provide an
additional, weaker comparison method.
> 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.
