On 5/3/11 10:00 AM, Vidar Ramdal wrote:
> The o.a.s.jcr.resource.internal.JcrResourceResolverFactoryImpl relies
> on a set of MapEntries to map URLs to paths. The current
> implementation of MapEntries reads the mapping specifications from
> /etc/map on initialization, and reloads the entire map when it
> receives a JCR event.
>
> In some scenarios it would be nice to be able to store mapping specs
> other places (scattered around the repository/resource tree, for
> instance). That is possible by registering a resource provider at
> /etc/map (thus overriding any JCR resource there), and populate the
> resource provider with whatever mappings you have. Then you need to
> trigger a JCR event at /etc/map to have JcrResourceResolverFactoryImpl
> reload its MapEntries.
>
> But this is a bit of a hack - the entire mapping mechanism is somewhat
> "JCR biased". IMO it would be better if the entire map specification
> was provided by a separate component, say a PathMapProvider (in lack
> of a better name):
>
> public interface PathMapProvider {
> public List<MapEntry> getResolveMaps();
> public Collection<MapEntry> getMapMaps();
> }
To be clear, are you suggesting that this would replace the existing
MapEntries or allow MapEntires to be augmented? I'd prefer the latter -
similar to how resource providers are used to augment the JCR resource tree.
While you're at it... I think MapEntry is a concrete class right now.
IMHO it'd be good as part of this refactoring to make it an interface.
Justin
>
> This is a bit rough, but it resembles the current MapEntries class. We
> might want to let PathMapProvider do more than just return those
> MapEntry'ies, but then we'll soon end up re-implementing
> JcrResourceResolver.map and .resolve.
>
> WDYT?
>
