[
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)
