Hey Denis,
I think the instruction for how to use togglz in an EE environment are a little bit too complicated ;-)
Yeah, these examples are pretty old and are using EJBs only without leveraging CDI which might not be so optimal.
I created for my project a very simple FeatureManagerProvider, see https://gist.github.com/denisa/9a400a0a082f21a49984, that I think do everything that's needed.I'd like to offer this for inclusion in togglz-cdi… should I just open and create a pull request?
Thanks for sharing your code. This would definitively an option. But actually I’m thinking about deprecating TogglzConfig in one of the next releases. In the future the primary way to configure Togglz should be to build a FeatureManager and tell your DI container about it. TogglzConfig came back from the days when I thought that it would be a good idea to let Togglz maintain the feature manager. But today every application uses some kind of DI frameworks which is way better to handle something like this.
So actually even to today your Togglz configuration can be done like this in case of CDI:
public class TogglzProducer {
@Produces
@ApplicationScoped
public FeatureManager build() {
new FeatureManagerBuilder()
.featureEnum(MyFeatures.class)
.stateRepository(new InMemoryStateRepository())
.userProvider(new NoOpUserProvider())
.build();
}
}
That’s all. No TogglzConfig needed and everything in one simple class.
I need to fine some time to work a bit on the documentation. But I think I’ve to do some more cleanup before these patterns can be documented.
Thanksdna