[
https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910125#action_12910125
]
Felix Meschberger commented on SLING-1778:
------------------------------------------
Looks interesting to me ....
@Carsten: I don't think ResourceDecorator would help here, because this
functionality really creates a virtual subtree in the resource tree root et the
symlink resource containing the subtree rooted at the symlink target.
Some comments to the patch:
* As for the symlink query: I would look for sling:symlinkTarget properties
and not the node type. The node type is mostly
interesting for applications/administrators but on an implementation
level, the property is what we are interested in
* sling:overlayable: I understand the concept, but: can we come up with a
nicer name ? ;-)
* The ResourceResolver field of the SymlinkManager should be private. Access
to the field for the SymlinkResourceProvider
should be possible using a getter method
* SymlinkResourceProvider.listChildren should probably support non-Symlink
resources, particularly if the symlink overlay is
enabled
* As a convenience it would be usefull to add the rootPath to the
service.description property of the provider service registration
* Not sure here: Would it make sense to have the sling:SymlinkResource type
also extend sling:Resource ?
* How is the symlink resource accessible ?
Symlink Resource Access: Provided you have a resource /content/symlink with a
symlink target set to /content/target. Thus accessing /content/symlink would
actually return you the /content/target resource, which makes perfect sense.
But: How is the actual /content/symlink resource accessible ? For example, if
we want to remove the symlink or if we want to retarget the symlink ?
> Symlinks
> --------
>
> Key: SLING-1778
> URL: https://issues.apache.org/jira/browse/SLING-1778
> Project: Sling
> Issue Type: New Feature
> Components: JCR
> Reporter: Julian Sedding
> Attachments: symlinks.patch
>
>
> I have implemented a ResourceProvider, which allows to create symlink nodes
> in the JCR repository. A symlink node has a sling:symlinkTarget property,
> which should contain a valid JCR path. JCR content from the
> sling:symlinkTarget path is then exposed below the symlink node.
> There is a mixin node type, sling:Symlink with a mandatory property
> sling:symlinkTarget and an optional property sling:overlayable. Additionally,
> there is a convenience node type, sling:SymlinkResource, which extends from
> sling:symlinkTarget and nt:unstructured.
> ResourceProvider instances are registered for existing symlinks when the
> bundle is started. Modifications are taken care of via JCR observation.
> To get started:
> * apply the attached patch to a trunk checkout
> * build and install the bundle
> * create a symlink node, pointing to some existing content
> * access the symlink node e.g. via a browser
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
