Hi Bertrand,
Am Freitag, den 18.01.2008, 11:39 +0100 schrieb Bertrand Delacretaz:
> On Jan 17, 2008 9:19 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
>
> > ...I finally somewhat finished the prototype implementation of the
> > "Everything is a Resource" concept and updated the wiki page....
>
> Thanks for this - I've had a look and I like what I see!
Thanks.
>
> One thing that came to mind: [1] lists a number of properties
> (sling.servlet.paths, sling.servlet.resourceTypes, etc.) used in
> resolving Servlets.
>
> I'm not sure if the range of "servlet selection properties" covers all
> cases - in some (rare but useful) cases it might be needed fo a
> Servlet to decide, by itself, if it can process the current request or
> not, by applying more complex rules that those properties allow.
>
> For some cases, I think it might be useful to create an interface like:
>
> interface CanProcessRequestDecision {
> boolean canProcess(SlingHttpServletRequest r);
> }
>
> that the class which resolves Servlets can use, to have a fully
> flexible selection mechanism. Most servlets won't implement this
> interface, so the normal case just needs an instanceof check to decide
> whether to use this or not.
>
> Would that fit into your design, if/when we need that?
Hmm, maybe there could be a solution: If the servlet has a path by which
the corresponding ServletResourceProvider may be attached into the
virtual resource tree, the ServletResourceProvider could then on request
select a servlet which it deems most appropriate and call the
canProcess() (or similar) method before actually returning the servlet.
This may e.g. be of interest to support JSR-311 UriTemplate with
variables.
> Also, is there any notion of priorities in Resource resolution in your
> design? I'm a bit worried about being dependent on the loading order
> of OSGi bundles, for example, in cases where two Servlets from
> different bundles have the same set of selection properties.
Yes: all ResourceProviders are combined into a tree accessed by path.
When resolving a resource, the on ResourceProvider with the longest
matching root path is selected and asked for the resource. If the
ResourceProvider cannot return a resource, the second longest matching
ResourceProvider is taken until the root provider (the JCR Resource
Provider serving "/") is checked. There is one implementation limitation
currently: For a given root path, only a single ResourceProvider can be
registered.
This mechanism is similar to *nix file system mount, where the
ResourceResolver are the mounted filesystems and the ResourceProvider
root paths are the mount points. Unlike *nix file system mount, the
subtrees of ResourceProviders may overlap.
Thus it is possible for two different Servlets serving the same resource
type but different extensions to be correctly selected.
Hope, this helps.
Regards
Felix
>
> -Bertrand
>
> [1] http://cwiki.apache.org/confluence/display/SLING/Everything+is+a+Resource
