[
https://issues.apache.org/jira/browse/SLING-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13749500#comment-13749500
]
Carsten Ziegeler commented on SLING-2076:
-----------------------------------------
I think the provider approach is not suited for this case - the different
mappings have to be aggregated/merged by the implementation in order to call
them in a meaningfull order (longest match first). In addition, mappings might
change at any time. If we would use the provider approach, we would have to
call all providers each time a mapping is handled, merge the results and apply
the mappings. This doesn't sound like a fast solution.
Of course a provider could indicate whether it has changed since the last time,
but still, once a provider a changes, this will block all map handling until
the list of mappings is updated.
The current implementation uses an async background thread avoiding any
blocking.
Therefore I think we should do an inverse approach: we define a manager like
service (don't have a good name yet), which can be called by providers
(provider is not an interface) whenever the provider has an update. The
provider uses an identififer together with the new set of mappings. So
basically this is the same way the OSGi installer works today, where providers
inform the installer about changes.
In this case we can do the processing in the background inside the manager, and
simply switch to the new mapping once the calculation is done
> Make MapEntries more dynamic
> ----------------------------
>
> Key: SLING-2076
> URL: https://issues.apache.org/jira/browse/SLING-2076
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
> Affects Versions: JCR Resource 2.0.10
> Reporter: Vidar S. Ramdal
> Assignee: Vidar S. Ramdal
>
> In some scenarios it would be nice to be able to store mapping specs other
> places than under /etc/map (for instance scattered around the
> repository/resource tree, or in an external XML file).
> It would be better if the entire map specification was provided by a separate
> service. The current MapEntries would act as the default implementation.
> Mailing list discussion: http://markmail.org/thread/5ww634sqarxtudks
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
