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.
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.
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 ? Ian (doing this will probably remove the need for SLING-1129)
