SPI requirement for NoteIds of referenceable Nodes

[Julian Reschke <ju...@gmx.de>]

Hi,

it seems that currently JCR2SPI assumes that the NoteIds returned for 
referenceable nodes actually do contain the UUID of that Node -- if the 
SPI implementation returns an absolute path based NodeID instead, 
JCR2SPI's Node.getUUID() implementation fails.

Proposals:

Either

1) Decide that this is how things are supposed to work, and just 
document it. Drawback: there may be repositories that have referencable 
nodes but path-based lookup still is more efficient (however, in that 
case the implementation could build a custom NodeId that contains both).

or

2) Change JCR2SPI to that it does not make that assumption, but instead 
retrieves the value of the jcr:uuid property.

Additional thought: before making a decision on this we may want to look 
at what new requirements JSR283 brings to the table.

BR, Julian

Re: SPI requirement for NodeIds of referenceable Nodes

[Angela Schreiber <an...@day.com>]

hi julian

> it seems that currently JCR2SPI assumes that the NodeIds returned for 
> referenceable nodes actually do contain the UUID of that Node -- if the 
> SPI implementation returns an absolute path based NodeID instead, 
> JCR2SPI's Node.getUUID() implementation fails.

the javadoc of IdFactory says:

"[...] In most cases such an item is also mix:referenceable but
  there is no restriction in that respect. An SPI implementation
  may also use a unique ID to identify non-referenceable nodes.[...]"

this doesn't explicitely require referenceable nodes
to expose their jcr:uuid as the ItemId#getUniqueID.

however, JSR 283 seems quite clear to me with respect
to the identifier of referenceable nodes:

"3.9 Referenceable Nodes
  [...] To be referenceable a node must be of type
  mix:referenceable [...] This node type adds an auto-created,
  mandatory, protected STRING property to the node, called
  jcr:uuid, which exposes the identifier of the node.
"

> Either
> 
> 1) Decide that this is how things are supposed to work, and just 
> document it. Drawback: there may be repositories that have referencable 
> nodes but path-based lookup still is more efficient (however, in that 
> case the implementation could build a custom NodeId that contains both).
> 
> or
> 
> 2) Change JCR2SPI to that it does not make that assumption, but instead 
> retrieves the value of the jcr:uuid property.
> 
> Additional thought: before making a decision on this we may want to look 
> at what new requirements JSR283 brings to the table.

generally, the assumption (and thus 1) looks more consistent to me.

but if i remember correctly michi actually ran into such a
problem with his SPI implementation... i think due to nt:resource
extending mix:referenceable in JSR 170 (btw. not any more
with JSR 283, see issue 428)).

basically, i wouldn't mind changing jcr2spi to retrieve the
value of the jcr:uuid property. but with respect to JSR 283
i have the impression that we would do better explicitely
mandating that referenceable nodes expose their uuid as
uniqueID part in order to be prepared for Item.getIdentifier.

regards
angela