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 >