[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13880895#comment-13880895 ] Stefan Seifert commented on SLING-1778: --- fyi: in the last weeks i finalized the first version of the superimposing resource provider and added a good (mock-based) unit test coverage for the whole implementation. to make it easer to play with it i did a first (inofficial) 0.1.0 release on github: https://github.com/stefanseifert/sling-superimposing/tree/v0.1.0 the API and node type/property names should be stable now. i included a README page as well to help setting it up. > 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: 130704_symlinks-0.0.4.patch, 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 was sent by Atlassian JIRA (v6.1.5#6160)
Re: [jira] [Commented] (SLING-1778) Symlinks
Hi Felix, On Mon, Oct 14, 2013 at 10:27 AM, Felix Meschberger wrote: >> Bertrand Delacretaz commented on SLING-1778: ... >> The shared components might go under bundles/commons/resourceprovider > ---Currently we have two non-JCR resource providers: Filesystem and Bundle > Resource Provider; both in bundles/extensions. > So either we continue with this and thus this new one goes into > bundles/extensions (or contrib/extensions), too. > Or we create a new subtree bundles/resource where we put all non-JCR resource > providers... bundles/resource sounds good to me, and we could move both resourceaccesssecurity and resourceresolver in there. The reusable "overlay" components of SLING-1778 (which is what I was talking about, not the resource provider itself) could then be a bundles/resource/overlay or bundles/resource/commons. -Bertrand
Re: [jira] [Commented] (SLING-1778) Symlinks
Hi Bertrand on where to potentially add such a resource provider... Am 14.10.2013 um 10:06 schrieb Bertrand Delacretaz (JIRA): > Bertrand Delacretaz commented on SLING-1778: > > > The shared components might go under bundles/commons/resourceprovider I think the commons area is basically "Sling-free" space and should remain such. Currently we have two non-JCR resource providers: Filesystem and Bundle Resource Provider; both in bundles/extensions. So either we continue with this and thus this new one goes into bundles/extensions (or contrib/extensions), too. Or we create a new subtree bundles/resource where we put all non-JCR resource providers (we could even move the Resource Resolver implementation bundle there). I have a slight preference for a new bundles/resource subtree. WDYT ? Regards Felix smime.p7s Description: S/MIME cryptographic signature
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793984#comment-13793984 ] Bertrand Delacretaz commented on SLING-1778: The shared components might go under bundles/commons/resourceprovider > 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: 130704_symlinks-0.0.4.patch, 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 was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792811#comment-13792811 ] Stefan Seifert commented on SLING-1778: --- fyi - if started some more work on this feature and created a github repository for the time being: https://github.com/stefanseifert/sling-superimposing i already renamed it to "superimposing resource provider" (until some comes up with a better name, although it will be quite time consuming to rename it again), and removed the JCR dependencies (one step missing concerning the overlay detection). i started adding unit tests, this is not completed yet. once this is done i will think about the possibilities to integrate the merge possibilities from SLING-2986 into it, or into a shared piece of code. it could be a good option to make the overlay part of this feature more flexible than it is currently. i'm not sure where such a "shared piece of merging code" should be placed within sling yet. as time permits i will do some more work on it the next days. > 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: 130704_symlinks-0.0.4.patch, 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 was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13779742#comment-13779742 ] Bertrand Delacretaz commented on SLING-1778: There's some overlap between SLING-1778 and SLING-2986, I'll discuss on list if and how we should merge these contributions, see upcoming "Resource merging and symlinks - two similar patches, do we unify?" thread on dev@sling.a.o. > 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: 130704_symlinks-0.0.4.patch, 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13779733#comment-13779733 ] Sander van Beek commented on SLING-1778: What about 'ghosting' or 'virtual pages'? Maybe this could be an end-user feature some day.. then a very abstract name might be confusing for them? Very cool feature by the way! > 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: 130704_symlinks-0.0.4.patch, 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13778612#comment-13778612 ] Carsten Ziegeler commented on SLING-1778: - I really prefer a name with a meaning - marketing names are not helpful on a technical level > 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: 130704_symlinks-0.0.4.patch, 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13778591#comment-13778591 ] Bertrand Delacretaz commented on SLING-1778: Slinglinks? > 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: 130704_symlinks-0.0.4.patch, 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13778590#comment-13778590 ] Carsten Ziegeler commented on SLING-1778: - I totally agree that symlink is not the best name, other names which came to my mind like Mirroring etc. are not quiet correct either. So why not Superimposing - it's a little bit long. If no one comes up with a better name, a new patch would be nice :) > 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: 130704_symlinks-0.0.4.patch, 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1313#comment-1313 ] Stefan Seifert commented on SLING-1778: --- fyi: today julian and myself held a lighting talk presentation at the adaptoTo() 2013 which visualizes the approach of this resource provider and delivers some background for the usecases: http://www.pro-vision.de/content/medialib/pro-vision/production/adaptto/2013/adaptto2013-lightning-superimposing-content-julian-sedding-stefa/_jcr_content/renditions/rendition.file/adaptto2013-lightning-superimposing-content-julian-sedding-stefan-seifert.pdf in context of this presentation we proposed choosing a new name for the resource provider, because the term "symlink" does not really fit for what the provider does: Superimposing Resource Provider for the non-native speakers: http://oxforddictionaries.com/definition/english/superimpose > 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: 130704_symlinks-0.0.4.patch, 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13715198#comment-13715198 ] Stefan Seifert commented on SLING-1778: --- no, there is really no magic in this sling symlink feature concerning advanced features like jcr queries or observation because the JCR does not "know" anything of the symlink. you have to handle this via code manually. but we added some public methods to the OSGI service managing the symlink to query the symlinks that are active currently, so you can check for search or observation hits if a symlink mapping exists for them in your code. > 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: 130704_symlinks-0.0.4.patch, 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13715195#comment-13715195 ] Dragos Dascalita Haut commented on SLING-1778: -- Sounds cool Stefan, thanks for making it clear. Did you notice any impact in the JCR query if symlinks nodes are involved in the query ? Can people query symlink nodes transparently (w/o knowing it's actually a 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: 130704_symlinks-0.0.4.patch, 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13715109#comment-13715109 ] Stefan Seifert commented on SLING-1778: --- this symlinks feature is implemented within the sling resource resolver infrastructure and can be applied to any resources, not only to JCR resources. the symlink concept is related but not similar to the shared node concept in JCR. the major differences are: * for JCR shared nodes there is no "master node", but a node can have multiple parents which have "equal rights". the symlink concept always has a master tree which is referenced by the symlink nodes. this usually matches better to a scenario where a dedicated team of editors is responsible for maintaining the master tree, while others are responsible only for the inherited tree and are not allowed to touch the master tree. * it is not possible to do things like "overlays" for some subtrees with JCR shared nodes, it is always exactly the same subtree that is linked to multiple parents. this is possible with this symlink patch (although it has some limitations, e.g. no control about the ordering of nodes that are added only in a inherited subtree) * the JCR specification leaves open several details for the implementation of the JCR repository, e.g. how to handle observation, JCR queries etc. Additionally the shared nodes feature seems to be rarely used and is not supported by all JCR-based CMS systems (e.g. Adobe CQ) > 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: 130704_symlinks-0.0.4.patch, 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13715045#comment-13715045 ] Dragos Dascalita Haut commented on SLING-1778: -- Maybe I'm not following correctly, but this issue made me wonder wether it tries to solve the same problem already solved by JCR with Shareable Nodes: http://www.day.com/specs/jcr/2.0/14_Shareable_Nodes.html Aren't shareable nodes working in the same way ? > 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: 130704_symlinks-0.0.4.patch, 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13714787#comment-13714787 ] Stefan Seifert commented on SLING-1778: --- no, our patch includes the initial patch from julian, so only our patch has to be applied. but the major part of our patch is the work initially contributed by julian, updated and enhanced by us. > 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: 130704_symlinks-0.0.4.patch, 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13702063#comment-13702063 ] Carsten Ziegeler commented on SLING-1778: - Just curious, why do you think we should add both patches to the extensions? > 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: 130704_symlinks-0.0.4.patch, 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. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913721#action_12913721 ] Carsten Ziegeler commented on SLING-1778: - If I see it correctly, the current implementation creates a resource provider for each symlink - I fear what happens if there are hundreds or thousands of symlinks > 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12913719#action_12913719 ] Carsten Ziegeler commented on SLING-1778: - I'm still not 100% convinced that a resource decorator couldn't solve the simple use case. I wouldn't go into merging or overlaying etc. just plain linking :) So, if you have resources /a/b1 and /a/b2 and symlink resources: /s/x1 -> /a/b2 /s/x2 -> /a/b1 Listing the children of /s gives you x1 and x2 - you could also have a non symlink resource /s/x3 there When requesting /s/x1 the resource decorator detects the symlink and returns a resource with the path /s/x1 but forwards all other methods to the resource of /a/b2. This of course works only for this level, so the question is just what a list children of /s/x1 returns or it is desired to allow deep links like /s/x1/bla/bli/blo which is then resolved to /a/b2/bla/bli/blo. > 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12912885#action_12912885 ] Andreas Fluegge commented on SLING-1778: Here my naive two cent to this topic: Why not simply extending the existing JcrResourceResolver to make it recognizing sling:symlink (or so) node types and make it return the referenced resource instead of the requested resource. This way there is no confusion in what this feature does: using a resource at one location as a 'placeholder' for a resource at some other location. Here some use cases where this feature would come in quite handy: 1. Site Navigation: Creating views to the content tailored to requirements of certain groups of users. These views are comparable to database views with the exception that they are static: a subtree contains only sling:symlink nodes to build up the 'view'... 2. Reducing redundancy by reusing existing resources in a different context. > 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.
[jira] Commented: (SLING-1778) Symlinks
[
https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910621#action_12910621
]
Justin Edelson commented on SLING-1778:
---
What I'm thinking is let's say...
Node /b/bar has property text1="one"
Node /b/baz has property text2="three"
Node /a/foo has property text="two"
Node /a/foo also has
sling:overlayPath = [/b/bar, /b/baz]
/a/foo.json will return
{
'text' : 'two',
'text1' : 'one',
'text2' : 'three',
'sling:overlayPath' : ['/b/bar', '/b/baz']
}
> 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910564#action_12910564 ] Julian Sedding commented on SLING-1778: --- @Justin > Any reason you couldn't have this be a multivalued property? I cannot imagine how that would work. Could you elaborate? Ok, thank you very much for the plentiful feedback! I'll take this through another iteration to incorporate your feedback. I'll drop the symlink idea in favor of the overlay mechanism. This should simplify the code a little and does make sense for me, since I don't have the symlink use-case at the moment. Unfortunately I don't have much time on my hands to work on this during my day job, so it may take a little while. > 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910198#action_12910198 ] Justin Edelson commented on SLING-1778: --- >> Just thinking out loud here, but how about *only* supporting overlays. I can >> see how >> overlays and symlinks are related, but they actually seems like different >> use cases. > >Ok, that could be easily done. What about the following: if we think of the >tree we want to overlay as the "shadow"-tree (again, I'm open for >better >names), we could define a property "sling:shadow" (or sling:shadowPath, >sling:shadowRoot?). "sling:shadow" would contain a string >value, the root >path of the "shadow"-tree. I liked "overlay" :) Any reason you couldn't have this be a multivalued property? > You suggest *only* supporting overlays. Would you drop the symlink use-case > entirely, implement it using shareable nodes or support it via > a sling:symlink (aka sling:symlinkTarget, playing the names-game again) > property? Supporting the last use-case would be trivial, however, it > might be confusing. I would say drop it entirely. It can be done with shareable nodes and it sounds like you don't need it. If someone needs it in the future, we can revisit. > 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910197#action_12910197 ] Bertrand Delacretaz commented on SLING-1778: I suggest sling:overlayPath for the property name. As for symlinks, I'd consider this a distinct problem, and if needed create a distinct component to handle them. I think that's what Justin meant. > 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910194#action_12910194 ] Julian Sedding commented on SLING-1778: --- > Just thinking out loud here, but how about *only* supporting overlays. I can > see how > overlays and symlinks are related, but they actually seems like different use > cases. Ok, that could be easily done. What about the following: if we think of the tree we want to overlay as the "shadow"-tree (again, I'm open for better names), we could define a property "sling:shadow" (or sling:shadowPath, sling:shadowRoot?). "sling:shadow" would contain a string value, the root path of the "shadow"-tree. You suggest *only* supporting overlays. Would you drop the symlink use-case entirely, implement it using shareable nodes or support it via a sling:symlink (aka sling:symlinkTarget, playing the names-game again) property? Supporting the last use-case would be trivial, however, it might be confusing. > 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910186#action_12910186 ] Bertrand Delacretaz commented on SLING-1778: > Just thinking out loud here, but how about *only* supporting overlays. I can > see how > overlays and symlinks are related, but they actually seems like different use > cases. I like that. > 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910184#action_12910184 ] Justin Edelson commented on SLING-1778: --- > However, the use-case I need to cover is creating a language tree in a WCM > scenario, which can be gradually overlayed with translated > pages Just thinking out loud here, but how about *only* supporting overlays. I can see how overlays and symlinks are related, but they actually seems like different use cases. > 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910179#action_12910179 ] Julian Sedding commented on SLING-1778: --- Thanks for the feedback so far! @Bertrand > Seems like this could be very confusing...if you really need it, I'd suggest > making it configurable and turned off by default. It is configurable via the sling:overlayable boolean property and the default, i.e. if the property is missing, is off. @Felix > * As for the symlink query: I would look for sling:symlinkTarget properties agreed > * sling:overlayable: I understand the concept, but: can we come up with a > nicer name ? ;-) Please feel free to suggest something more intuitive ;) > * The ResourceResolver field of the SymlinkManager should be private. Access > to the field for the SymlinkResourceProvider > should be possible using a getter method Yes, that should be private. I think it is not used by SymlinkResourceProvider at all. > * SymlinkResourceProvider.listChildren should probably support non-Symlink > resources, particularly if the symlink overlay is > enabled Yes, I was thinking about this. I don't think it's trivial, as the ResourceResolver might go into a recursion. That's the reason I'm using the JCR API in places. An option might be to directly query other ResourceProviders. > * As a convenience it would be usefull to add the rootPath to the > service.description property of the provider service registration Purely for information? Yes, makes sense. A web console plugin might also be useful. I was also playing with the thought of exposing SymlinkManager as a service and provide an API to e.g. list registered symlinks. > * Not sure here: Would it make sense to have the sling:SymlinkResource type > also extend sling:Resource ? Not sure either, probably won't hurt. What's the use of slingResource btw? > * How is the symlink resource accessible ? I used CRXDE lite for testing, which works via the Jackrabbit davx servlet. Therefore I don't know. Is the POST servlet purely JCR based? If that's the case, at least modifications would be possible. It seems, however, that a solution is needed to also view the symlink definition. Ideas welcome :) > ... one more thing: for us to be able to use this contribution you should > upload it with the "Grant license to ASF for inclusion in ASF works" button > checked. Thanks. That's a mistake, I meant to check this of course. @Justin I agree that shareable nodes could be an alternative way to explore this. However, the use-case I need to cover is creating a language tree in a WCM scenario, which can be gradually overlayed with translated pages. So the "with exception of overlayable" would have hurt. > 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910134#action_12910134 ] Justin Edelson commented on SLING-1778: --- with the exception of "overlayable", don't JCR 2 shareable nodes accomplish the same thing and have the advantage that the post servlet will work on all members of the shared set? > 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910126#action_12910126 ] Felix Meschberger commented on SLING-1778: -- ... one more thing: for us to be able to use this contribution you should upload it with the "Grant license to ASF for inclusion in ASF works" button checked. Thanks. > 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.
[jira] Commented: (SLING-1778) Symlinks
[ 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910120#action_12910120 ] Bertrand Delacretaz commented on SLING-1778: Thanks for the clarifcation. > Then if /a/foo has property sling:overlayable=true > (in addition to sling:symlinkTarget = /b/bar) > /a/foo/4/text is "four" Seems like this could be very confusing...if you really need it, I'd suggest making it configurable and turned off by default. IMO symlinks should mimic what happens in a unixish filesystem: if /a/foo has sling:simlinkTarget = /b/bar, I'd like /a/foo and everything under it to be the same tree as /b/bar. > 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910117#action_12910117 ] Julian Sedding commented on SLING-1778: --- @Carsten I didn't look into the ResourceDecorator mechanism, so I don't know if the same use-case could be implemented that way. But if you have input I'm certainly very interested. @Bertrand The example you gave is precisely what I had in mind and what the patch achieves. Additionally, extending your example, assume /a/foo/4 has property text="four" Then if /a/foo has property sling:overlayable=true (in addition to sling:symlinkTarget = /b/bar) /a/foo/text is "one" /a/foo/4/text is "four" /a/foo/4/2/text is "three" > 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910111#action_12910111 ] Bertrand Delacretaz commented on SLING-1778: > ...JCR content from the sling:symlinkTarget path is then exposed below the > symlink node... Not sure if I understand this correctly, can you confirm that the use case is as follows? Node /b/bar has property text="one" Node /b/bar/4/2 has property text="three" Node /a/foo has property text="two" Then if /a/foo has sling:simlinkTarget = /b/bar /a/foo/text is "one" /a/foo/4/2/text is "three" Is that correct? > 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.
[jira] Commented: (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910107#action_12910107 ] Carsten Ziegeler commented on SLING-1778: - I haven't looked into your patch yet, but what about using a ResourceDecorator instead of a provider - this avoids all observation stuff etc. > Symlinks > > > Key: SLING-1778 > URL: https://issues.apache.org/jira/browse/SLING-1778 > Project: Sling > Issue Type: New Feature >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.
