[
https://issues.apache.org/jira/browse/SLING-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840114#comment-16840114
]
Carsten Ziegeler commented on SLING-8411:
-----------------------------------------
[~jsedding] The use cases for this are basically similar to the use cases for a
resource provider; its not just mounting another JCR repository. If you look at
the current implementation of the file resource provider, it already adds a lot
of functionality like allowing to adapt a resource to a node etc. However, that
approach has its limitations. For example you don't find these nodes if you
traverse down from a JCR session. That's when this is a solution as it is
applied on a lower level. Of course, it still has some limitations but it gets
you a lot further than a resource provider approach for these scenarios.
As Karl pointed out, the impact for existing installations is basically zero.
[~karlpauls] I think the hooks are more a last resort, meaning only if you have
to use the same interface to register but need to avoid that others see this
service then it can be used. But as you note, hooks have some problems. The
developer of such a repository supported by the described approach needs to
opt-in, it can't just magically happen for any repository implementation.
Therefore I see no problem with using the marker interface as this is a clear
sign of opting in.
> Provide a way to bifurcate a repository path to a provider mount
> ----------------------------------------------------------------
>
> Key: SLING-8411
> URL: https://issues.apache.org/jira/browse/SLING-8411
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Affects Versions: JCR Base 3.0.6
> Reporter: Karl Pauls
> Assignee: Karl Pauls
> Priority: Major
> Fix For: JCR Base 3.0.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> While one would normally use a resource provider to extend the content tree,
> sometimes, that can be not enough a code might make assumptions about the
> resources being actually being backed by JCR. This can be problematic as for
> example, a given resource can not necessarily be adapted to a Node nor be
> found via a Session.
> Hence, a similar approach on the JCR level allowing developers to mount
> content into sub trees of the repository itself can be helpful to be able to
> support these kind of usecase. We should provide a hook for a repository
> mount that takes over a given subpath by wrapping repositories returned by
> the base and dispatching to the mount when the request is for a given subpath.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
