[jira] [Commented] (SLING-2076) Make MapEntries more dynamic

["Carsten Ziegeler (JIRA)" <ji...@apache.org>]

    [ 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