[
https://issues.apache.org/jira/browse/JCR-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12530980
]
Michael Dürig commented on JCR-1140:
------------------------------------
Ok I got it. The source of confusion stems from the javadoc of ItemId which
only covers the case for already existing items (i.e. instances of Item). It
says that if an item can be identified with an unique ID then an ItemId
identifying this item will use that ID (and not the path). However, when an
item is about to be constructed, RepositoryService.getItemInfos() might get
called with a NodeId using a Path even though the item will be identifiable
with an unique ID.
In short: from a spi2something developer's perspective the documentation gives
the impression that RepositoryService.getItemInfos() is always called with the
same ItemId (in respect to ID and path) for a given NodeInfo. But this is not
the case for items with uniqueIds.
> NodeId for root node should not be hardcoded in jcr2spi
> -------------------------------------------------------
>
> Key: JCR-1140
> URL: https://issues.apache.org/jira/browse/JCR-1140
> Project: Jackrabbit
> Issue Type: Bug
> Components: SPI
> Reporter: Michael Dürig
>
> org.apache.jackrabbit.jcr2spi.hierarchy.NodeEntryImpl.getId() always returns
> idFactory.createNodeId((String) null, Path.ROOT) for the root node although a
> repository might want to reference the root node by UUID. NodeId.getId()
> breaks the contract of org.apache.jackrabbit.spi.ItemId which for this case
> states: "The item can not be identified with a unique ID and none of its
> ancestors can be identified with a unique ID. The item is identified by an
> absolute path".
> I suggest to change the implementation such that when NodeId.getId() needs to
> return the NodeId of the root node a round trip to
> org.apache.jackrabbit.spi.RepositoryService.getRootId() is done.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
