ResourceProvider binding.

[Ian Boston <ie...@tfd.co.uk>]

I may be missing something basic, so please tell me if I am.

IIUC, ResourceProvider implementations are bound by the  
JcrResourceResolverFactory.bindResourceProvider(...) into a tree of  
ResourceProviderEntries where there is only one ResourceProvider bound  
to any one path location.

This makes sense from a direct path to Resource mapping, but feels  
wrong when Sling Resources are bound to metadata and not to paths.

In the case of the JcrResourceProvider, it (IIRC) is bound to / and  
any further resolution of the Resource happens in the  
JcrResourceProvider (provided there isnt a different ResourceProvider  
bound to the Path). If the path doesn't exist in JCR then thats it...  
the JcrResourceProvider returns null and none of the other  
ResourceProviders get a chance to look at the request.

I would like to propose a change where at each location in the  
ResourceProviderEntry tree can contain more than one ResourceProvider  
in a ordered or linked list so that each ResourceProvider is checked  
in turn and if none produce a Resource, the resource really doesn't  
exist.

AFAICT, where a Sling instance does not currently generate  
ResourceProviderEntryException from about line 237 in  
ResourceProviderEntry, this will have no impact.
Where a Sling instance does generate exceptions new  
ResourceProviderEntries will be added to the list.
To ensure that the list is immune from startup order, ResourceProvider  
implementations will need a priority.

WDYT ?
Crazy proposal ?
Ian

(doing this will probably remove the need for SLING-1129)

Re: ResourceProvider binding.

[Ian Boston <ie...@tfd.co.uk>]

On 1 Oct 2009, at 13:52, Felix Meschberger wrote:
>>>
>>> If so, this would be another argument for your proposal.
>>
>> I will try and prove that this will work, so the full impact is  
>> known.



http://codereview.appspot.com/124090

I have put a patch set up here, with some unit tests.
It will work for on conflicting ResourceProviders and for conflicting  
ResourceProviders if they also implement an appropriate Comparator impl.

(conflicting ones are order dependent)

WDYT?

Ian


>>
>> Ian
>>
>>>
>>> Regards
>>> Felix
>>
>>
>

Re: ResourceProvider binding.

[Ian Boston <ie...@tfd.co.uk>]

On 1 Oct 2009, at 13:52, Felix Meschberger wrote:

> Hi,
>
> Ian Boston schrieb:
>>
>> On 1 Oct 2009, at 09:02, Felix Meschberger wrote:
>>
>>> Hi,
>>>
>>> Ian Boston schrieb:
>>>> I may be missing something basic, so please tell me if I am.
>>>>
>>>> IIUC, ResourceProvider implementations are bound by the
>>>> JcrResourceResolverFactory.bindResourceProvider(...) into a tree of
>>>> ResourceProviderEntries where there is only one ResourceProvider  
>>>> bound
>>>> to any one path location.
>>>
>>> That's correct.
>>>
>>>> This makes sense from a direct path to Resource mapping, but  
>>>> feels wrong
>>>> when Sling Resources are bound to metadata and not to paths.
>>>>
>>>> In the case of the JcrResourceProvider, it (IIRC) is bound to /  
>>>> and any
>>>> further resolution of the Resource happens in the  
>>>> JcrResourceProvider
>>>> (provided there isnt a different ResourceProvider bound to the  
>>>> Path). If
>>>> the path doesn't exist in JCR then thats it... the  
>>>> JcrResourceProvider
>>>> returns null and none of the other ResourceProviders get a chance  
>>>> to
>>>> look at the request.
>>>
>>> That's not correct.
>>>
>>> In fact the ResourceProviderEntry instances are organized in a  
>>> tree and
>>> when looking up a resource this tree is walked from the leafs  
>>> (matching
>>> the (prefix of the) path towards the root (JcrResourceProvider). The
>>> lowest level ResourceProviderEntry willing to provide a Resource  
>>> wins.
>>>
>>> Thus, actually, the JcrResourceProvider only gets a chance at  
>>> providing
>>> a JCR based resource if no other ResourceProviderEntry provides a
>>> resource.
>>
>> We are agreed, my description was lacking.
>>
>>>
>>> Nevertheless ...
>>>
>>>> I would like to propose a change where at each location in the
>>>> ResourceProviderEntry tree can contain more than one  
>>>> ResourceProvider in
>>>> a ordered or linked list so that each ResourceProvider is checked  
>>>> in
>>>> turn and if none produce a Resource, the resource really doesn't  
>>>> exist.
>>>>
>>>> AFAICT, where a Sling instance does not currently generate
>>>> ResourceProviderEntryException from about line 237 in
>>>> ResourceProviderEntry, this will have no impact.
>>>> Where a Sling instance does generate exceptions new
>>>> ResourceProviderEntries will be added to the list.
>>>> To ensure that the list is immune from startup order,  
>>>> ResourceProvider
>>>> implementations will need a priority.
>>>>
>>>> WDYT ?
>>>> Crazy proposal ?
>>>
>>> I think that this might be an interesting proposal - if only to  
>>> handle
>>> some corner cases in a more user-friendly manner (such as two or  
>>> more
>>> servles registering for the same resource path).
>>
>>
>> I just want to check I have the analysis right in my head.
>>
>> The corner case is to allow two or more *ResourceProviders* to  
>> register
>> at the same path, producing a Resource based on some other criteria  
>> not
>> handled by the other ResourceProviders for the identical path.
>>
>> eg
>> registered at "/" we might have
>> MyResourceProvider
>> JcrResourceProvider
>>
>> in that order.
>>
>> MyResourceProvider would only respond if the path did not exist in in
>> the JCR *and* one of the ancestor nodes had a specific
>> sling:resourceType otherwise it would do nothing allowing
>> JcrResourceProvider to handle the creation of the Resource.
>
> Actually, not exactly: given the above example of the  
> MyResourceProvider
> and JcrResourceProvider both registered at "/" and the
> MyResourceProvider be more important, the MyResourceProvider would be
> asked *before* the JcrResourceProvider, thus only if the
> MyResourceProvider does not have the resource (path is considered  
> only),
> the JcrResourceProvider is asked.

:), I think we said the same thing.
the MyResourceProvider would have

Session session = resourceResolver.adaptTo(Session.class);
if ( session.itemExists(path) ) {
   // the item exists, let JcrResourceProvider handle the  
ResourceCreation.
   return null;
}
// more code to generate some form of synthetic.

>
> Turned around, you can implement your fall-back resource provider with
> very low priority, such that it comes last.
>
> Still you might want SLING-1129 implemented in case you only want to
> create your custom "non-existing-resource" if all options have been
> exhausted.

Possibly, but I would much rather use the standard Sling Resource  
bundle and not have to unpack it and extend it.



>
>>
>> after that point, Servlets binding to resource type would process the
>> request as normal.
>>
>> (you mentioned "servles" above, I think you meant  
>> ResourceProviders ?)
>
> Yes: Servlets are registered as OSGi services. The servlet/resolver
> bundle picks these servlets destined at Sling up and registers a
> ServletResourceProvider for each such Servlet service.
>
> It may now be the case that two or more servlets happen to be  
> registered
> with the same path. In this case a collision between
> ServletResourceProviders happens which is only halfway resolved  
> right now.
>
> Having the option to register more than one ResourceProvider at the  
> same
> path, we could better solve this and be able "over-write" existing  
> servlets.

ahh ok, agreed
Ian

>
> Regards
> Felix
>
>>
>>
>>>
>>>> (doing this will probably remove the need for SLING-1129)
>>>
>>> If so, this would be another argument for your proposal.
>>
>> I will try and prove that this will work, so the full impact is  
>> known.
>>
>> Ian
>>
>>>
>>> Regards
>>> Felix
>>
>>
>

Re: ResourceProvider binding.

[Felix Meschberger <fm...@gmail.com>]

Hi,

Ian Boston schrieb:
> 
> On 1 Oct 2009, at 09:02, Felix Meschberger wrote:
> 
>> Hi,
>>
>> Ian Boston schrieb:
>>> I may be missing something basic, so please tell me if I am.
>>>
>>> IIUC, ResourceProvider implementations are bound by the
>>> JcrResourceResolverFactory.bindResourceProvider(...) into a tree of
>>> ResourceProviderEntries where there is only one ResourceProvider bound
>>> to any one path location.
>>
>> That's correct.
>>
>>> This makes sense from a direct path to Resource mapping, but feels wrong
>>> when Sling Resources are bound to metadata and not to paths.
>>>
>>> In the case of the JcrResourceProvider, it (IIRC) is bound to / and any
>>> further resolution of the Resource happens in the JcrResourceProvider
>>> (provided there isnt a different ResourceProvider bound to the Path). If
>>> the path doesn't exist in JCR then thats it... the JcrResourceProvider
>>> returns null and none of the other ResourceProviders get a chance to
>>> look at the request.
>>
>> That's not correct.
>>
>> In fact the ResourceProviderEntry instances are organized in a tree and
>> when looking up a resource this tree is walked from the leafs (matching
>> the (prefix of the) path towards the root (JcrResourceProvider). The
>> lowest level ResourceProviderEntry willing to provide a Resource wins.
>>
>> Thus, actually, the JcrResourceProvider only gets a chance at providing
>> a JCR based resource if no other ResourceProviderEntry provides a
>> resource.
> 
> We are agreed, my description was lacking.
> 
>>
>> Nevertheless ...
>>
>>> I would like to propose a change where at each location in the
>>> ResourceProviderEntry tree can contain more than one ResourceProvider in
>>> a ordered or linked list so that each ResourceProvider is checked in
>>> turn and if none produce a Resource, the resource really doesn't exist.
>>>
>>> AFAICT, where a Sling instance does not currently generate
>>> ResourceProviderEntryException from about line 237 in
>>> ResourceProviderEntry, this will have no impact.
>>> Where a Sling instance does generate exceptions new
>>> ResourceProviderEntries will be added to the list.
>>> To ensure that the list is immune from startup order, ResourceProvider
>>> implementations will need a priority.
>>>
>>> WDYT ?
>>> Crazy proposal ?
>>
>> I think that this might be an interesting proposal - if only to handle
>> some corner cases in a more user-friendly manner (such as two or more
>> servles registering for the same resource path).
> 
> 
> I just want to check I have the analysis right in my head.
> 
> The corner case is to allow two or more *ResourceProviders* to register
> at the same path, producing a Resource based on some other criteria not
> handled by the other ResourceProviders for the identical path.
> 
> eg
> registered at "/" we might have
> MyResourceProvider
> JcrResourceProvider
> 
> in that order.
> 
> MyResourceProvider would only respond if the path did not exist in in
> the JCR *and* one of the ancestor nodes had a specific
> sling:resourceType otherwise it would do nothing allowing
> JcrResourceProvider to handle the creation of the Resource.

Actually, not exactly: given the above example of the MyResourceProvider
and JcrResourceProvider both registered at "/" and the
MyResourceProvider be more important, the MyResourceProvider would be
asked *before* the JcrResourceProvider, thus only if the
MyResourceProvider does not have the resource (path is considered only),
the JcrResourceProvider is asked.

Turned around, you can implement your fall-back resource provider with
very low priority, such that it comes last.

Still you might want SLING-1129 implemented in case you only want to
create your custom "non-existing-resource" if all options have been
exhausted.

> 
> after that point, Servlets binding to resource type would process the
> request as normal.
> 
> (you mentioned "servles" above, I think you meant ResourceProviders ?)

Yes: Servlets are registered as OSGi services. The servlet/resolver
bundle picks these servlets destined at Sling up and registers a
ServletResourceProvider for each such Servlet service.

It may now be the case that two or more servlets happen to be registered
with the same path. In this case a collision between
ServletResourceProviders happens which is only halfway resolved right now.

Having the option to register more than one ResourceProvider at the same
path, we could better solve this and be able "over-write" existing servlets.

Regards
Felix

> 
> 
>>
>>> (doing this will probably remove the need for SLING-1129)
>>
>> If so, this would be another argument for your proposal.
> 
> I will try and prove that this will work, so the full impact is known.
> 
> Ian
> 
>>
>> Regards
>> Felix
> 
> 

Re: ResourceProvider binding.

[Ian Boston <ie...@tfd.co.uk>]

On 1 Oct 2009, at 09:02, Felix Meschberger wrote:

> Hi,
>
> Ian Boston schrieb:
>> I may be missing something basic, so please tell me if I am.
>>
>> IIUC, ResourceProvider implementations are bound by the
>> JcrResourceResolverFactory.bindResourceProvider(...) into a tree of
>> ResourceProviderEntries where there is only one ResourceProvider  
>> bound
>> to any one path location.
>
> That's correct.
>
>> This makes sense from a direct path to Resource mapping, but feels  
>> wrong
>> when Sling Resources are bound to metadata and not to paths.
>>
>> In the case of the JcrResourceProvider, it (IIRC) is bound to / and  
>> any
>> further resolution of the Resource happens in the JcrResourceProvider
>> (provided there isnt a different ResourceProvider bound to the  
>> Path). If
>> the path doesn't exist in JCR then thats it... the  
>> JcrResourceProvider
>> returns null and none of the other ResourceProviders get a chance to
>> look at the request.
>
> That's not correct.
>
> In fact the ResourceProviderEntry instances are organized in a tree  
> and
> when looking up a resource this tree is walked from the leafs  
> (matching
> the (prefix of the) path towards the root (JcrResourceProvider). The
> lowest level ResourceProviderEntry willing to provide a Resource wins.
>
> Thus, actually, the JcrResourceProvider only gets a chance at  
> providing
> a JCR based resource if no other ResourceProviderEntry provides a  
> resource.

We are agreed, my description was lacking.

>
> Nevertheless ...
>
>> I would like to propose a change where at each location in the
>> ResourceProviderEntry tree can contain more than one  
>> ResourceProvider in
>> a ordered or linked list so that each ResourceProvider is checked in
>> turn and if none produce a Resource, the resource really doesn't  
>> exist.
>>
>> AFAICT, where a Sling instance does not currently generate
>> ResourceProviderEntryException from about line 237 in
>> ResourceProviderEntry, this will have no impact.
>> Where a Sling instance does generate exceptions new
>> ResourceProviderEntries will be added to the list.
>> To ensure that the list is immune from startup order,  
>> ResourceProvider
>> implementations will need a priority.
>>
>> WDYT ?
>> Crazy proposal ?
>
> I think that this might be an interesting proposal - if only to handle
> some corner cases in a more user-friendly manner (such as two or more
> servles registering for the same resource path).


I just want to check I have the analysis right in my head.

The corner case is to allow two or more *ResourceProviders* to  
register at the same path, producing a Resource based on some other  
criteria not handled by the other ResourceProviders for the identical  
path.

eg
registered at "/" we might have
MyResourceProvider
JcrResourceProvider

in that order.

MyResourceProvider would only respond if the path did not exist in in  
the JCR *and* one of the ancestor nodes had a specific  
sling:resourceType otherwise it would do nothing allowing  
JcrResourceProvider to handle the creation of the Resource.

after that point, Servlets binding to resource type would process the  
request as normal.

(you mentioned "servles" above, I think you meant ResourceProviders ?)


>
>> (doing this will probably remove the need for SLING-1129)
>
> If so, this would be another argument for your proposal.

I will try and prove that this will work, so the full impact is known.

Ian

>
> Regards
> Felix

Re: ResourceProvider binding.

[Felix Meschberger <fm...@gmail.com>]

Hi,

Ian Boston schrieb:
> I may be missing something basic, so please tell me if I am.
> 
> IIUC, ResourceProvider implementations are bound by the
> JcrResourceResolverFactory.bindResourceProvider(...) into a tree of
> ResourceProviderEntries where there is only one ResourceProvider bound
> to any one path location.

That's correct.

> This makes sense from a direct path to Resource mapping, but feels wrong
> when Sling Resources are bound to metadata and not to paths.
> 
> In the case of the JcrResourceProvider, it (IIRC) is bound to / and any
> further resolution of the Resource happens in the JcrResourceProvider
> (provided there isnt a different ResourceProvider bound to the Path). If
> the path doesn't exist in JCR then thats it... the JcrResourceProvider
> returns null and none of the other ResourceProviders get a chance to
> look at the request.

That's not correct.

In fact the ResourceProviderEntry instances are organized in a tree and
when looking up a resource this tree is walked from the leafs (matching
the (prefix of the) path towards the root (JcrResourceProvider). The
lowest level ResourceProviderEntry willing to provide a Resource wins.

Thus, actually, the JcrResourceProvider only gets a chance at providing
a JCR based resource if no other ResourceProviderEntry provides a resource.

Nevertheless ...

> I would like to propose a change where at each location in the
> ResourceProviderEntry tree can contain more than one ResourceProvider in
> a ordered or linked list so that each ResourceProvider is checked in
> turn and if none produce a Resource, the resource really doesn't exist.
> 
> AFAICT, where a Sling instance does not currently generate
> ResourceProviderEntryException from about line 237 in
> ResourceProviderEntry, this will have no impact.
> Where a Sling instance does generate exceptions new
> ResourceProviderEntries will be added to the list.
> To ensure that the list is immune from startup order, ResourceProvider
> implementations will need a priority.
> 
> WDYT ?
> Crazy proposal ?

I think that this might be an interesting proposal - if only to handle
some corner cases in a more user-friendly manner (such as two or more
servles registering for the same resource path).

> (doing this will probably remove the need for SLING-1129)

If so, this would be another argument for your proposal.

Regards
Felix