>> We could provide a way through the ResolveContext to get the "parent" >> provider and check that one for a resource. > >I think that should work for these cases, yes. This would make any >cascading the responsibility of the ResourceProvider implementation, >similar to how servlet filters work.
+1 with the current resourceprovider concept such a "request the parent resource resolver" was missing, because of this the superimposing resource provider had to fall back to the JCR API for this making it JCR-dependent. >I have some concerns about the provider always owning the root, >however. I understand that this makes it easier to have good >performance by default. as long as it is cheap to have multiple (perhaps lots) of resource provider instances this should not be problem. with the superimposing content provider e.g. it may be required to have thousands of instances each assigned to one specific root. stefan
