Hi, Thanks for the feedback Julian.
On 07.07.20, 10:45, "Julian Sedding" <jsedd...@gmail.com> wrote: > 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. If used as a short-lived object, that is indeed a problem. My intention with the FeatureToggle is actually that it is long-lived, though it can obviously also be used differently. The try-with-resource block in the tests is just convenient. > 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. This is by design. It is valid to have multiple feature toggles registered with the same name. It's not the primary use case, but they can be used that way. > 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. I'm not sure I understand. Can you elaborate what you have in mind? > Regarding the API, I would probably rename FeatureToggle to Feature and > FeatureToggleAdapter to FeatureToggle. But that's of course a matter of > taste. Thanks for the suggestion. I like it. > Also, I would add an "isEnabled" method to FeatureToggleAdapter, in > order to allow the code setting the toggle to introspect the current > state. I considered this as well, but did not see a use case for it. What would you do with this method? Regards Marcel
