[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17839511#comment-17839511
]
Radu Cotescu edited comment on SLING-12300 at 4/22/24 7:01 AM:
---------------------------------------------------------------
[~enorman], nobody trivialised your concerns. I’m not sure if everyone is
familiarised with the UUIDv4 standard that Oak uses for the {{jcr:uuid}}
property and I was just trying to explain the problem space. In addition, you
expressed that there would be security issues by implementing this feature, but
didn’t explain which. Predictability is not a security concern IMO if you
correctly use ACLs.
[~paul.bjorkstrand], for my use-case I only need those resources addressable by
ID at the Java API level. The application that is built on top controls the URL
space, but I wanted to use the Sling API for accessing the resource tree. You
could ask why the contradiction: update the JCR resource provider to use a
feature exposed only by JCR, but consume it via Sling?! Well, the Sling API is
just easier to use and simpler to understand for developers than the JCR one.
Adding a new Resource Provider could also be an option, but in the end it would
perform the same function in the same way: it would offer a way to retrieve
resources by ID from its mount root, whichever that will be.
I also thought about extending the Sling Resource API, but given that right now
only one commonly used provider generates IDs for the resources it creates I
thought it would be too complex and not provide so many gains.
I will obviously not push something that the Sling community doesn’t agree
with, but I would like that we discuss the alternatives and pick the solution
that makes the most sense in terms of effort/benefits.
was (Author: radu.cotescu):
[~enorman], nobody trivialised your concerns. I’m not sure if everyone is
familiarised with the UUIDv4 standard that Oak uses for the {{jcr:uuid}}
property and I was just trying to explain the problem space. In addition, you
expressed that there would be security issues by implementing this feature, but
didn’t explain which. Predictability is not a security concern IMO if you
correctly use ACLs.
[~paul.bjorkstrand], for my use-case I only need those resources addressable by
ID at the Java API level. The application that is built on top controls the URL
space, but I wanted to use the Sling API for accessing the resource tree. You
could ask why the contradiction: update the JCR resource provider to use a
feature exposed only by JCR, but consume it via Sling?! Well, the Sling API is
just easier to use and simpler to understand for developers than the JCR one.
Adding a new Resource Provider could also be an option, but in the end it would
perform the same function in the same way: it would offer a way to retrieve
resources by ID from its mount root, whichever that will be.
I also thought about extending the Sling Resource API, but given that right now
only one commonly use provider generates IDs for the resources it creates I
thought it would be too complex and not provide so many gains.
I will obviously not push something that the Sling community doesn’t agree
with, but I would like that we discuss the alternatives and pick the solution
that makes the most sense in terms of effort/benefits.
> Provide a way to retrieve a JCR backed resource by its node identifier
> ----------------------------------------------------------------------
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Radu Cotescu
> Assignee: Radu Cotescu
> Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
