You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Vidar Ramdal <vr...@apache.org> on 2011/05/03 16:00:17 UTC
Separating MapEntries from JcrResourceResolver
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 <vi...@webstep.no>
Webstep AS - http://www.webstep.no
Besøksadresse: Lilleakerveien 8, 0283 Oslo
Postadresse: Postboks 66, 1324 Lysaker
Re: Separating MapEntries from JcrResourceResolver
Posted by Carsten Ziegeler <cz...@apache.org>.
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
cziegeler@apache.org
Re: Separating MapEntries from JcrResourceResolver
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, May 3, 2011 at 4:00 PM, Vidar Ramdal <vr...@apache.org> wrote:
> ...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();
> }
>
Sounds like a good idea, to make things more dynamic.
-Bertrand
Re: Separating MapEntries from JcrResourceResolver
Posted by Julian Sedding <js...@gmail.com>.
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 <ju...@gmail.com> 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?
>>
>
>
Re: Separating MapEntries from JcrResourceResolver
Posted by Justin Edelson <ju...@gmail.com>.
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?
>