Configuring Activity Strategy Parameters via Annotations

161 views
Skip to first unread message

Kai Hofstetter

unread,
Oct 5, 2015, 3:10:20 PM10/5/15
to togglz-dev
Hi,

we are using Togglz and we really like it!

I especially like the way features are configured in the source code and how you can add a label via annotations.

We need some default values for the parameters of the activation strategies. I know you can do that via a property file.

But I like the idea of adding the activation strategy parameters to the feature in the source code via annotation, so that the whole feature is configured in one place...

Something like this:

public enum MyFeatures implements Feature {

    @EnabledByDefault
    @Label("First Feature")
    FEATURE_ONE,

    @Label("Second Feature")
    @ActivationStrategy(id = UsernameActivationStrategy.ID,
            activationParameter = {@ActivationParameter(name = UsernameActivationStrategy.PARAM_USERS, value = "person1,ck,person2"),
                                   @ActivationParameter(name =....)})
    FEATURE_TWO;
    
    public boolean isActive() {
        return FeatureContext.getFeatureManager().isActive(this);
    }
    
}

What do you think?

I would send a pull request if you like the idea :-)

Thanks,
Kai

Christian Kaltepoth

unread,
Oct 8, 2015, 9:34:35 AM10/8/15
to toggl...@googlegroups.com
Hey,

sorry for the delayed response. I was quite busy in my job and didn't find much time to watch the mailing list.

Very interesting idea. Configuring features in source code may be useful in certain scenarios. However, in this case you are loosing one of the central features of Togglz, which is the ability to toggle features at runtime.

I think the only thing that makes sense here is to provided a "default" activation strategy in the spirit of the @EnabledByDefault annotation. This would basically mean that Togglz would first check the StateRepository for any stored feature state. If it doesn't find anything in the repository, it would look for defaults via annotations (Actually this is hidden behind the FeatureMetadata interface, because Togglz also support other backends).

So it could look like this:

public enum MyFeatures implements Feature {

    @Label("Second Feature")
    @EnabledByDefault
    @DefaultActivationStrategy(
        id = UsernameActivationStrategy.ID,
        parameters = {

             @ActivationParameter(name = UsernameActivationStrategy.PARAM_USERS, value = "person1,ck,person2")
        }
    )
    FEATURE_TWO;
   
}

Here is the relevant code from the DefaultFeatureManager that currently handles this:


And I think to get this into the API in a clean way, we would have to remove this method:


And replace it with something like:

  FeatureState getDefaultFeatureState();


Thoughts?

Christian

--
Christian Kaltepoth

Kai Hofstetter

unread,
Oct 9, 2015, 2:01:02 AM10/9/15
to togglz-dev
Hi Christian,

sounds great. Yes, I would just configure default activation strategies via annotation if there is no FeatureState from a StateRepository.
Like you wrote, it would be somewhat similar to the @EnabledByDefault annotation.

Thank you for pointing me to the source code!
It doesn't seem to be difficult to implement and it would be exactly what we need!

I would write a pull request, if it is ok for you.

Thank you,
Kai

Christian Kaltepoth

unread,
Oct 9, 2015, 10:58:23 AM10/9/15
to toggl...@googlegroups.com
Hey Kai,

awesome. Looking forward to your pull request. :)

A few notes regarding your contribution:
  • There is an Eclipse code format profile in the Git repo. It would be great if you could use it.
  • It would be great to have a few tests in place for this new feature
  • Feel free to ask if you have any questions. :)
Regarding the implementation: 

I really think there should be some kind of FeatureMetaData#getDefaultFeatureState() which could basically replace FeatureMetaData#isEnabledByDefault(). I guess this makes sense. Please note that there are multiple implementations for this interface. Especially the one for feature definition via property files. We should keep this implementation and the property format backwards compatible. But it would be ok if the property-based implementation wouldn't support defining activation strategies but only the "enabled by default" for now.

Beside refactoring FeatureMetaData you will have to also modify DefaultFeatureManager#isActive() which is the heart of Togglz. :) But I think this should be easy.

Christian

Anupriya Chhabra

unread,
Feb 27, 2017, 9:07:40 PM2/27/17
to togglz-dev
Hey Kai and Christian

Has this been implemented yet. I have a similar requirement in one of my projects.

Regards
Anupriya

Christian Kaltepoth

unread,
Feb 28, 2017, 2:44:36 AM2/28/17
to toggl...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages