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?
--
Vidar S. Ramdal <vidar.ram...@webstep.no>
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 66, 1324 Lysaker
