[ https://issues.apache.org/jira/browse/SLING-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16839216#comment-16839216 ]
Karl Pauls commented on SLING-8411: ----------------------------------- [~jsedding], all of this said (I broke out some comments to address them separately), to your main point: I was experimenting with hooks initially however, that doesn't really work for all scenarios because of the way the base is using inheritance. The subtle point is that the repository registered as a service isn't limit to be a repository - it has to extend from the base classes (and as such, must be at least a repository) however, it can be other things in addition. That makes it impossible to proxy it in the general case (unless I'm missing something). I do agree it would be nicer that way but I don't see how todo it. Regardless, I agree that the current requirement to implement the marker interfaces adds a high hurdle for providing a mount. The reason I did that was that I wanted to avoid confusion with services registered as repositories (and used by other). Clearly, we could just lookup services with a special service property, but that would again, make it difficult in scenarios where other code is looking for such services. The alternative I see would be for the base to just look for object (and a special service property). That way, one would be free to register without the interface (to avoid confusion). Granted, we could use your findHook idea at least on this level by filtering out the used services (that would work as well I guess) but I don't personally like hooks that much as they create ordering problems (I.e. it would require that the hook is registered before the provider comes along). Ultimately, I guess what I'm saying is: I would propose to: * keep this as part of the base (due to the problem mentioned above) but, * remove the requirement for the marker interface (either by using object or by providing hooks) and, * work on removing the limit to one mount in the future. Does that makes sense to you (and if so, would you rather have the object interface or a hook)? > 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)