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
