[jira] [Comment Edited] (SLING-9662) Introduce a Resource Mapping SPI

["Georg Henzler (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-9662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17180571#comment-17180571 ] 

Georg Henzler edited comment on SLING-9662 at 8/19/20, 2:18 PM:
----------------------------------------------------------------

One open question is how we deal with the lifecycle of ResourceResolvers (and ResourceResolverFactory resp.) compared to the ResourceToUriMapper services - ATM the lifecycle is independent [1], references to ResourceResolver/ResourceResolverFactory remain intact if a ResourceToUriMapper vanishes (e.g. during a deployment) and the respective mapping will just be "missing" during this time (which could potentially lead to problems, but a ServiceUnavailableFilter can be configured to mitigate). I think this behaviour is in line with changes to /etc/maps (here the bundle is also not restarted upon changes IIRC). We could introduce a config property "requiredResourceToUriMapperServices" that the activator for the ResourceResolverFactory waits for, but if not needed I would like to avoid the complexity.

[~cziegeler] [~rombert] Do you see a problem with the current referencing approach as it is on branch [1]? 

[1] https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/9a703ac38bee64c6ebe73b5c4df3b56307fdaed0/src/main/java/org/apache/sling/resourceresolver/impl/mappingchain/ResourceUriMappingChain.java#L53


was (Author: henzlerg):
One open question is how we deal the the lifecycle of the ResourceResolver (and ResourceResolverFactory resp.) compared to the ResourceToUriMapper services - ATM the lifecycle is independent [1], references to ResourceResolver/ResourceResolverFactory remain intact if a ResourceToUriMapper vanishes (e.g. during a deployment) and the respective mapping will be just "missing" during this time (which could potentially lead to problems, but a ServiceUnavailableFilter can be configured to mitigate). I think this behaviour is in line with changes to /etc/maps (here the bundle is also not restarted upon changes IIRC). We could introduce a config property "requiredResourceToUriMapperServices" that the activator for the ResourceResolverFactory waits for, but if not needed I would like to avoid the complexity.

[~cziegeler] [~rombert] Do you see a problem with the current approach as it is on branch [1]? 

[1] https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/9a703ac38bee64c6ebe73b5c4df3b56307fdaed0/src/main/java/org/apache/sling/resourceresolver/impl/mappingchain/ResourceUriMappingChain.java#L53

> Introduce a Resource Mapping SPI
> --------------------------------
>
>                 Key: SLING-9662
>                 URL: https://issues.apache.org/jira/browse/SLING-9662
>             Project: Sling
>          Issue Type: New Feature
>          Components: API
>            Reporter: Georg Henzler
>            Assignee: Georg Henzler
>            Priority: Major
>
> Introduce a simple SPI that allows to contribute to the resource resolver's map() and resolve() methods:
> *ResourceUri:*
> General purpose class to represent a ResourceUri (like e.g. a link in an html <a> tag). Immutable itself but adjustable using the builder pattern. Part of the Sling API and can be used anywhere to simplify handling/modification of Sling ResourceUri. Implements RequestPathInfo. ResourceUri can be created easily from a String, a Request, a Resource, a URI or a RequestPathInfo.
> *ResourceToUriMapper:*
> SPI interface to be implemented as OSGi Service. All registered services build a conceptual chain sorted by service ranking. The resource link is passed through the chain while any ResourceToUriMapper chain member may or may not make adjustments to the resource link.
>  rr.resolve() passes through the chain starting at the ResourceToUriMapper with the <strong>highest</strong> service ranking and rr.map() passes through the chain starting at the ResourceToUriMapper with the <strong>lowest</strong> service ranking
> _Mailing List References:_
>  [https://www.mail-archive.com/dev@sling.apache.org/msg93537.html] 
>  [https://www.mail-archive.com/dev@sling.apache.org/msg87736.html]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)