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

Reply via email to