[ 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.