Without having read the code, my understanding may be flawed. If that's the case please tell me so.
When generalizing the MapEntries code to allow additional providers, I can see two approaches. Firstly, a provider can contribute entries to a static map, secondly, a provider gets the unmapped string and returns a mapping or null. My impression is that the first approach, i.e. contributing to a static list, is being discussed here. IMHO the second approach, i.e. handing the string to the provider for mapping, would be desirable. This would allow for rule-based mappings, which should allow greater flexibility. Just some thoughts. Regards Julian On Mon, May 9, 2011 at 4:46 PM, Justin Edelson <[email protected]> wrote: > 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? >> > >
