[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 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
Re: [jira] [Commented] (SLING-1778) Symlinks
Hi Felix, On Mon, Oct 14, 2013 at 10:27 AM, Felix Meschberger fmesc...@adobe.com 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
[jira] [Commented] (SLING-1778) Symlinks
[ https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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.
