The thread context resource resolver (referred to as the ResourceResolverHelper by Felix) is available with the recent API 2.8.0 release from the ResourceResolverFactory. So this could be used in services
Carsten 2014-09-03 5:26 GMT+02:00 Felix Meschberger <[email protected]>: > 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 > > -- Carsten Ziegeler Adobe Research Switzerland [email protected]
