[
https://issues.apache.org/jira/browse/SLING-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282071#comment-14282071
]
Carsten Ziegeler commented on SLING-4327:
-----------------------------------------
Thanks for the use cases, I think its clear now :)
Just a set of random thoughts:
Basically what you want/need is a differently configured resource resolver - in
your case you want a different mapping, but I could also see the use case to
use different search paths etc. This needs to be done in a way which is not
depending on implementation details.
Now, one way would be to enhance the factory interface - however this works
with one feature but as soon as we want to change the default behaviour of more
than one feature, the factory interface gets bloated with methods.
The other thing why I was thinking about using the auth info is that you might
want to execute a request in a different context, like having a preview of how
things on publish look like; but maybe we should leave this out of the picture
for now. Not sure.
For the mapping use case, we could make the mapping a service and then provide
a way to "bind" the current resource resolver to a different service instance.
> 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)
