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
