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