[
https://issues.apache.org/jira/browse/SLING-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16838579#comment-16838579
]
Julian Sedding commented on SLING-8411:
---------------------------------------
[~karlpauls] I was looking for a more "businessy" use-case, like: "I have two
distinct (legacy?) JCR repositories that I cannot migrate into a single one,
and I would like to expose a unified view of both on the JCR level."
In any case, thank you for adding a unit-test!
To me the architecture of your change feels wrong. Rather than cramming this
feature into the JCR Base bundle, I would prefer to see this as a new module.
The new module would itself extend from the JCR Base bundle and provide a way
to configure multiple mounts (a bit like fstab). It would consume services of
type {{Repository}} that have e.g. a {{repository.id}} registration property.
Additionally (and optionally), it could hide these services from other
consumers using an OSGi {{FindHook}}.
This should require only little changes to other implementations of JCR Base in
order to allow them to be consumed. E.g. the "JCR Oak Repository Server" would
need to be modified to allow multiple configurations, maybe an option to
prevent registration as {{SlingRepository}} (i.e. only register as
{{Repository}}) and add a {{repository.id}} property.
I think most of your code could be taken as-is (i.e. the federating JCR
implementation aka all the Proxy* classes).
Furthermore, there are a few things about your PR, that I think could be
improved:
- in the test you register and retrieve {{Repository}} instances as
{{RepositoryMount}} services. This is confusing and it's not immediately
obvious why and how this, i.e. it violates the [principle of least
surprise|https://en.wikipedia.org/wiki/Principle_of_least_astonishment].
- In the JCR RangeIterator implementations you return "0" for {{getSize()}}.
This violates the JCR spec. If you don't want to implement them, return "-1".
- The mount points are defined on the individual {{RepositoryMount}} (or indeed
{{Repository}}), i.e. the opposite to what fstab does, making it hard to find
out what is actually configured.
- The limitation to the (implied) root mount and one other mount seems pretty
arbitrary.
> Provide a way to bifurcat 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)
