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 > >
