Hi The Features service can be used by non-request processing threads, e.g. by background threads/tasks.
Currently, though, it will only global feature state and not context sensitive state. With the proposed addition of the ResourceResolverHelper, which may place the ResourceResolver created from a ResourceResolverFactory into the thread context, the FeatureManager could leverage that and create a context with the ResourceResolver directly if the HttpServletRequest is not available, such as in background contexts. With such a ResourceResolver you can then provide the Tenant information for your own Feature implementation. Regards Felix Am 02.09.2014 um 05:58 schrieb Timothée Maret <[email protected]>: > Hi, > > In our service, we provide a set of features which can be enabled/disabled > per tenant. > Our tenants implementation is based on the Sling Tenant API and we are > thinking to leverage the Sling Feature flags API to represent our features. > From our application POV, we would need to implement this logical signature > > status = enable(tenantId, featureName) > > Looking at the Sling feature flags API, the signature we should implement > looks like [0] > > status = feature(featureName).enable(request, resolver) > > where the request and resolver are essentially the context provided by the > features manager implementation. > > So, implementing our use case would be possible as we can derive a tenantId > from a resolver > > status = feature(featureName).enable(tenantId(resolver)) > > With the current features manager implementation, this would be possible > only when features are checked upon a HTTP request as the features manager > would be able to provide a meaningful context. > > However, with background services, the features manager would naturally not > be able to provide a meaningful context (currently the resolver and request > are null), thus our implementation would be useless for those use cases. > According to the javadoc in [2], it would also not be possible to > explicitly provide our own context implementation (that would embed the > tenantId, or a resource resolver that can be reduced to the tenantId) using > the API. > > An option would be to implement our own features manager which would take > the tenantId in consideration, however I believe it would make more sense > to leverage the existing implementation and allow to pass custom contexts > to it (essentially removing the comment in [2]). > > Another improvement may be to allow passing a map of properties via the > context. This way, a background service could pass directly the relevant > information to the Feature, instead of having to leverage a proxy > ResourceResolver or HttpServletRequest instance. > > Anyway, are feature flags supposed to be accessible from background > services (as wished in [1]) ? > If yes, what is the recommended way to use contextual feature flags from > background services ? > > Regards, > > Timothee > > [0] > https://github.com/apache/sling/blob/trunk/bundles/extensions/feature-flags/src/main/java/org/apache/sling/featureflags/Feature.java#L70 > [1] http://markmail.org/message/rueoiuacmft5fdet > [2] > https://github.com/apache/sling/blob/trunk/bundles/extensions/feature-flags/src/main/java/org/apache/sling/featureflags/Feature.java#L60
