>So, finally, I agree that baking the feature flag support directly into the >ResourceResolver implementation is suboptimal, it is probably still the most >comprehensive and complete solution to the requirements. And I cannot conceive >plugin hooks (at this point) to define such that we can do feature flag >plugins.
I think that we should not put it directly into ResourceResolver, because if resourceResolver does not give me a resource if feature is disabled, Resource will stop existing for me. There will be no way to access that resource using ResourceResolver api i.e. let's say I want to remove sling:feature attribute from that resource, I can't do that. ResourceResolverDecorator should be the way to go (implementation could be restricted i.e. queryResources not supported), additionally providing a servlet filter as Alex suggested. Thanks, Amit -----Original Message----- From: Felix Meschberger [mailto:fmesc...@adobe.com] Sent: 15 November 2013 13:11 To: dev@sling.apache.org Subject: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype) Hi TL;DR: Long discussion on why I think Feature flag support should currently be baked into the ResourceResolver implementation. I am forking of this discussion now to step back a bit and really look into what we expect from Feature flag support in the ResourceResolver. I go by the main resource access or methods there, so: * resolve() -> Resource Calculates a virtual list of resource candidates and returns the first one. Applying feature flags, it might not return the first one. Another level of features could be applied to supporting feature flags in the /etc/map mappings leading to the list of candidate resources. * map -> String The input path is first converted into a resource, which may have a feature flag applied. In addition to applying a feature flag to the resource which is finally mapped the /etc/map mappings can also be "filtered" with feature flags. * getResource() -> Resource For absolute path its a single yes/no question: Is the resource visible or not according to the feature flag. For relative paths its not as simple since the ResourceResolver iterates the search path looking for a resource. So each canidate is looked at and has to have its feature flag inspected. (feature flags of ancestors are ignored; only feature flags in the candidate resource itself are considered; so no feature flag inheritance down the tree) * getParentResource() -> Resource This is not an interesting case because it accesses the parent resource using the absolute path and we would not expect to get null here (except if the argument resource is the root resource). * listChildren -> Iterator<Resource> * getChildren -> Iterable<Resource> * queryResources -> Iterator<Map<String,Object>> * findResources -> Iterator<Resource> Simple case here: We just exclude child resources whose feature flag refers to a disabled feature. What options do we have ? * ResourceResolverDecorator (to be specced/implemented): Will have to do extra work getResource to iterate the search path for relative resources to consider the feature flag - might optimize by only iterating if the actual getResource method returns a resource with a disabled feature flag. Iterator<Resource> can simply be decorated, too. queryResources is harder again because this might contain results from queries which should not be included according to the feature flag (so each entry would have to be inspected, if at all possible). Also: A ResourceDecorator cannot properly handle feature flags in /etc/map mappings at all and also support feature flags on resolveResource is probably hard to implement because the list of canidate resources is influence by /etc/map mappings so a decorator would have to replicate that work. * ResourceAccessGate: This is not leveraged by all ResourceProviders and we expressely leave it to these services to indicate the use of a gate. Defining Feature flag support to have all ResourceProviders require to leverage ResourceAccessGate sounds contradictionary. Also, while a case can be made for the Feature flag to be some kind of an access gate, the actual idea of the ResourceAccessGate is actual access control as in secure access. Also we just want to apply the feature flag "gate" to all Resourceproviders not a generic ACL gate which may also be defined. * Bake Feature support into the ResourceResolver implementation: This solves the ResourceResolverDecorator problems by being able to handle Feature flags early. But is bears the problem of overloading the implementation with the feature flag support. So, finally, I agree that baking the feature flag support directly into the ResourceResolver implementation is suboptimal, it is probably still the most comprehensive and complete solution to the requirements. And I cannot conceive plugin hooks (at this point) to define such that we can do feature flag plugins. Is the ServletResolver also affected by feature flags ? Probably not: The ResourceResolver does filter on resource feature flags and the SlingScriptAdapterFactory may apply feature flags for scripting languages and Servlet services may implement OptingServlet and query feature flags in the accepts method. Regards Felix
