BUILD FAILURE: Jackrabbit Oak - Build # 2812 - Still Failing
The Apache Jenkins build system has built Jackrabbit Oak (build #2812) Status: Still Failing Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/2812/ to view the results. Changes: [fortino] OAK-9119: support order by clause in oak-search-elastic Test results: All tests passed<>
BUILD FAILURE: Jackrabbit Oak - Build # 2811 - Still Failing
The Apache Jenkins build system has built Jackrabbit Oak (build #2811) Status: Still Failing Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/2811/ to view the results. Changes: [mkataria] OAK-9126: TestFramework: create tests for both lucene and elastic Test results: All tests passed<>
Re: [Proposal] Feature toggles
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 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 >
Re: [Proposal] Feature toggles
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 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 > 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 >>
Re: [Proposal] Feature toggles
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" 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 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 > 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 >>
Re: [Proposal] Feature toggles
Hi, Thanks for the feedback Julian. On 07.07.20, 10:45, "Julian Sedding" 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