[
https://issues.apache.org/jira/browse/SLING-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282253#comment-14282253
]
Felix Meschberger commented on SLING-4327:
------------------------------------------
Hmm, this becomes an interesting discussion and is growing in scope from the
original request. That's good, because it opens thinking to a bigger picture...
So here's my take:
* I agree with [~cziegeler] in that if we decide to do something like that, it
should go into the AuthentictionInfo map. I could think it would be ok to
broaden the scope of that map and we could define and document accordingly.
* This would indeed allow to create custom search paths. The problem we have to
clarify, though, is that across a Sling instance we are using ResourceResolver
instances in various contexts. One such context is the Servlet/Script Resolver
which has its own ResourceResolver because it needs special privileges to find
the scripts. If we go with custom search paths, we must not forget this
situation... Also custom search paths might present a whole slew of
consequential problems. Maybe we should not go that route ... Not a topic for
this issue, anyway.
* Carsten mentioned a mapping service: We have been discussing before that we
should split the mapping functionality out of the core ResourceResolver
implementation and make it more pluggable. I think that would be a good idea to
do.
* Having a way to reference a mapping service with an abstract name like
"publish" or "author" or "default" instead of having to explicitly name a
mapping configuration location in the authentication info seems superior to me.
Because this allows the "special" configuration to be encapsulated away from
the consumer of the functionality.
So to conclude:
* We might add support to name a different Mapping Service in the
authentication info map
* We should define a MappingService which has its own configuration and which
can be referred to by identifier
* We have to see how we migrate the current ResourceResolverImpl configuration
to the new Mapping Service configuration
> 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)