jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-789) PathElement.equals doesn't handle INDEX_UNDEFINED
Date Thu, 29 Mar 2007 20:40:25 GMT

    [ 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.

View raw message