> let's say I want to remove sling:feature attribute from that resource, I > can't do that
I don't think that will be a real problem in practice. Removing the sling:feature property from a resource enables the feature. Therefore you may as well enable the feature (e.g. via configuration) before removing the property. The property only marks a resource as being restricted by a feature flag, it doesn't toggle the feature flag. Regards Julian On Fri, Nov 15, 2013 at 2:11 PM, Amit.. Gupta. <amitg...@adobe.com> wrote: >>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
