You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Kamil Ciecierski (JIRA)" <ji...@apache.org> on 2015/01/17 15:19:34 UTC
[jira] [Updated] (SLING-4327) ResourceResolver aware of any
mappings
[ https://issues.apache.org/jira/browse/SLING-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kamil Ciecierski updated SLING-4327:
------------------------------------
Description:
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}
was:
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 change:
{code}
ResourceResolver getResourceResolver(Map<String, Object> authenticationInfo, String customRootMap) throws LoginException;
ResourceResolver getAdministrativeResourceResolver(Map<String, Object> authenticationInfo, String customRootMap) throws LoginException;
{code}
> 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)