Hi,

I wanted to keep dependencies to a minimum and provide flexibility
how features are actually toggled. The proposal only depends on the
already existing Oak concept of a Whiteboard. In most cases this
indeed means a feature toggle is registered as an OSGi service.

Regards
 Marcel

On 07.07.20, 11:24, "Roy Teeuwen" <r...@teeuwen.be> wrote:

Hey Marcel,

As I also mentioned in the JIRA ticket. What is the reasoning to put this in 
Oak code, and not directly in Felix? I see no clear connection with Oak and you 
even use a lot of OSGi concepts

Greets,
Roy

> On 7 Jul 2020, at 10:45, Julian Sedding <jsedd...@gmail.com> wrote:
> 
> Hi Marcel,
> 
> I think the API is elegant. Short of running "feature" code in a
> closure, a "try with resource" block encourages developers to clearly
> delimit the block of code that is subject to the feature toggle,
> hopefully resulting in readable code.
> 
> I'm not sure about the aspect of the implementation, that
> FeatureToggle is Closeable and probably often short-lived. Given that
> the FeatureToggleAdapter is registered with the whiteboard, and thus
> likely with the OSGi service registry, this _may_ put unnecessary load
> on the service registry. Furthermore, enabling/disabling the toggle
> would need to be done in a way that respects this dynamism. And
> lastly, even if a FeatureToggleAdapter is already registered for a
> feature, a new service would be registered if the same code was run in
> a second thread.
> 
> From an OSGi perspective, I would lean towards a long-lived singleton
> service that can be toggled. The FeatureToggle could then be adjusted
> to retrieve the matching service if available, or otherwise register
> its own.
> 
> Regarding the API, I would probably rename FeatureToggle to Feature
> and FeatureToggleAdapter to FeatureToggle. But that's of course a
> matter of taste. Also, I would add an "isEnabled" method to
> FeatureToggleAdapter, in order to allow the code setting the toggle to
> introspect the current state.
> 
> Regards
> Julian
> 
> 
> On Mon, Jul 6, 2020 at 7:10 PM Marcel Reutegger
> <mreut...@adobe.com.invalid> wrote:
>> 
>> Hi,
>> 
>> There is a proposal ready in OAK-9132 [0] that introduces the concept of
>> feature toggles [1]. A FeatureToggle is basically a boolean value that
>> controls whether some new feature is available. The implementation uses
>> the Oak Whiteboard to register a feature toggle. It is then up to
>> another bundle to control the state of the feature toggles at
>> initialization and/or runtime.
>> 
>> A very simple implementation that wires feature toggles to system
>> properties is presented in OAK-9132. More sophisticated implementations
>> that talk to a central feature toggle service are also easy to implement
>> with an OSGi component that keeps track of registered feature toggles.
>> 
>> Feedback welcome.
>> 
>> Regards
>> Marcel
>> 
>> [0] https://issues.apache.org/jira/browse/OAK-9132
>> [1] https://martinfowler.com/articles/feature-toggles.html
>> 


Reply via email to