it may be worth it revisiting the tenant api in regards to feature flags
as well and have some sort of way to have feature flag dependent osgi
properties.
Ruben
On 12/6/2013 12:51 PM, Justin Edelson wrote:
On Fri, Dec 6, 2013 at 12:10 PM, Alexander Klimetschek
<[email protected]> wrote:
On 06.12.2013, at 08:08, Felix Meschberger <[email protected]> wrote:
Think back and forth I really think that we should put feature flag support
into the ResourceResolver proper.
I agree.
+1
Henry wrote it well: "So, fundamentally all that the framework can do
is provide a way to define flags, provide a switch panel and a way to
extend it, and API to check flags in condition statements. How and
where each flag is used is up to the developer of a specific
application feature."
The ResourceResolver is such an application feature which needs to be
enhanced to support feature flags. We probably have some others in
Sling as well.
Regards,
Justin
Another completely open question is: the resource resolver is not tied to a
request, backend services use it as well. So if the feature flag is driven by
the request, how do you handle that for those service resolvers?
AFAIU, the two major cases for feature flags are a) user dependent and b) global on/off.
But in both cases it can depend on the application whether those services have to fall
under the flags or not. For example, you might have an observation going on that does
something advanced (*). Should it run even if it's "feature" is off (as nobody
will use the results as long as the feature is off)? Or should it be totally disabled?
This is a question often only the application can decide.
Say the service resolvers are using admin sessions or some service users, then
you could turn it on/off based on them - to be in line with user-based request
resolvers in case a). But it could also be that you have flag a where you must
handle it in application code and don't want it handled in the resolver
already. Thus you either make it configurable on the flag itself what impact it
has or you actually ask for a resource resolver with special feature flags in
the first place (or not, getting a standard one).
Also, I mentioned observation: it's a JCR level thing that wouldn't be affected
by Sling resource resolver feature flags.
Just thinking out loud here, not sure what the cleanest approach would be...
Cheers,
Alex
