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
