Hi,
yes, I agree separating this makes sense.
For the interface I'm not that sure as I don't have any concrete use
cases so far. The PathMapProvider looks fine to me, we definitly should
work on a public version of the MapEntry class (keeping the static stuff
private etc.)
I think, as this is public api it should go into the Sling API - next to
resource provider etc.
The current implementation is too tightly bound to JCR - I think we have
a bug to base the implementation on the resource tree instead. This is
something we should do in addition.
Regards
Carsten
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();
> }
>
> 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?
>
--
Carsten Ziegeler
[email protected]
