[
https://issues.apache.org/jira/browse/JCR-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154327#comment-13154327
]
Julian Reschke commented on JCR-2540:
-------------------------------------
Summarizing the remaining open issue:
We fail to compute an identifier for NODE_REMOVE events because computing the
local identifier currently requires a lookup (PROPFIND) of the remote
resource's properties (UUID, name, index). We *do* have the remote resource's
identifier (as part of the event), but it's not necessarily the same locally,
because the way identifiers are assigned is not the same (jackrabbit-core has
uuids for all nodes, spi2dav only for referenceable nodes).
Things we can do to improve things:
(1) Make sure that the URIResolver cache is populated with mappings for all
nodes the client is touching (right now this is not the case).
(2) When not able to lookup the remote resource, compute an identifier solely
based on the remote resource's href; that's not necessarily the one the client
might have seen before, but it might be better than "null". Also note that if
we do (1), we may already have the identifier. For nodes created by other
sessions I think it's acceptable that the identifiers returned with REMOVAL
events are slightly off (there are also RepositoryDescriptors reporting
identifier stability we could tune).
(3) Avoid doing the remote PROPFIND when it was a REMOVE event. If we ever get
a 207, it'll be for a different resource anyway.
Feedback appreciated...
> spi2dav : move/reorder not properly handled by observation
> ----------------------------------------------------------
>
> Key: JCR-2540
> URL: https://issues.apache.org/jira/browse/JCR-2540
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server, jackrabbit-spi2dav, JCR 2.0,
> observation
> Affects Versions: 2.0
> Reporter: angela
> Assignee: Julian Reschke
>
> all TCK tests including move or reorder fail in the setup jcr2spi -
> spi2dav(ex) - jcr-server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
