[
https://issues.apache.org/jira/browse/SLING-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14281849#comment-14281849
]
Julian Sedding commented on SLING-4327:
---------------------------------------
[~kamil.ciecierski] I believe your use-case is already possible without the
additional argument. The mapping root path is configurable. Combine this with
the OSGi installer's capability to install configurations depending on the
runmode, the flexibility has always been sufficient for me.
E.g. provide two different configurations like this:
{code}
/apps/foo/config.publish/org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
jcr:primaryType="sling:OsgiConfig"
resource.resolver.map.location="/etc/maps/publish"
/apps/foo/config.author/org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl
jcr:primaryType="sling:OsgiConfig"
resource.resolver.map.location="/etc/maps/author"
{code}
If you require additional flexibility for e.g. test and prod environments, just
add the runmodes: e.g. {{/apps/foo/config.author.test}}.
> ResourceResolver aware of any mappings
> --------------------------------------
>
> Key: SLING-4327
> URL: https://issues.apache.org/jira/browse/SLING-4327
> Project: Sling
> Issue Type: Wish
> Components: API
> Reporter: Kamil Ciecierski
>
> Provide ability to create a ResourceResolver which is aware of any mappings,
> for example by providing proper argument mappingPath. In case of AEM it would
> be possible to use publish instance mapping present under etc/publish.map to
> on author instance.
> To achieve that the CommonResourceResolverFactoryImpl could be implementing
> methods getResourceResolver() and getAdministrativeResourceResolver() with
> additional argument defining the mapping location. The advantage of this
> solution is that the created ResourceResolver can be used many times with the
> same mappings. The drawback is that the mappings configuration will be found
> and cached when they resourceresolver will be used for the first time - there
> is no possibility to define the list of working mappings before.
> The proposal of API extension:
> {code}
> ResourceResolver getResourceResolver(Map<String, Object> authenticationInfo,
> String customRootMap) throws LoginException;
>
> ResourceResolver getAdministrativeResourceResolver(Map<String, Object>
> authenticationInfo, String customRootMap) throws LoginException;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
