features endpoint

[spencergibb]

Allows modules to declare features and display if they enabled or not. Originally, this was the /cloud endpoint, but /features made more sense as I was building it.

Endpoint output looks like this

{
    "enabled": [
        {
            "type": "Spring Cloud Bus",
            "name": "org.springframework.cloud.consul.bus.ConsulBusAutoConfiguration$$EnhancerBySpringCGLIB$$a9c6359d",
            "version": "1.1.0.BUILD-SNAPSHOT",
            "vendor": "Pivotal Software, Inc."
        },
        {
            "type": "Circuit Breaker",
            "name": "com.netflix.hystrix.contrib.javanica.aop.aspectj.HystrixCommandAspect",
            "version": "1.4.13",
            "vendor": null
        },
        {
            "type": "DiscoveryClient",
            "name": "org.springframework.cloud.consul.discovery.ConsulDiscoveryClient",
            "version": "1.1.0.BUILD-SNAPSHOT",
            "vendor": "Pivotal Software, Inc."
        },
        {
            "type": "LoadBalancerClient",
            "name": "org.springframework.cloud.netflix.ribbon.RibbonLoadBalancerClient",
            "version": "1.1.0.BUILD-SNAPSHOT",
            "vendor": "Pivotal Software, Inc."
        }
    ],
    "disabled": [
        "LockService"
    ]
}

Feature types

There are two types of 'features': abstract and named.

• Abstract features are features where an interface or abstract class is defined that an implementation creates, such as DiscoveryClient, LoadBalancerClient or LockService. The abstract class or interface is used to find a bean of that type in the context. The version displayed is bean.getClass().getPackage().getImplementationVersion().
• Named features are features that don't have a particular class they implement, such as "Circuit Breaker", "API Gateway", "Spring Cloud Bus", etc... These features require a name and a bean type.

Howto declare features:

Any module can declare any number of HasFeature beans. Examples:

@Bean
public HasFeatures commonsFeatures() {
  return HasFeatures.abstractFeatures(DiscoveryClient.class, LoadBalancerClient.class);
}

@Bean
public HasFeatures consulFeatures() {
  return HasFeatures.namedFeatures(
    new NamedFeature("Spring Cloud Bus", ConsulBusAutoConfiguration.class),
    new NamedFeature("Circuit Breaker", HystrixCommandAspect.class));
}

@Bean
HasFeatures localFeatures() {
  return HasFeatures.builder()
      .abstractFeature(Foo.class)
      .namedFeature(new NamedFeature("Bar Feature", Bar.class))
      .abstractFeature(Baz.class)
      .build();
}

Each of these beans should go in an appropriately guarded @Configuration.

[spencergibb]

/cc @dussab @dsyer @mstine @adriancole @joshlong

[mstine]

This is slick. 👍

[codefromthecrypt]

looks good. maybe add a test/example of how disabling works?

[spencergibb]

A feature shows up as disabled if there is not bean of that type. There's a potential that features won't show up in disabled at all, say "Circuit Breaker": the feature definition needs to be guarded by @ConditionalOnClass(HystrixCommandAspect.class) or something, so it wouldn't even show up (Unless there was an option for a String class name).

[codefromthecrypt]

ps probably overengineering, but i might use buildVersion. That would only matter if we have an abstract notion of version.

ps. here's some plugin/feature/extension related prior api art

http://developer.openstack.org/api-ref-identity-v3.html
http://docs.rackspace.com/servers/api/v2/cs-devguide/content/get_extensions.html
http://apidocs.cloudfoundry.org/215/feature_flags/get_all_feature_flags.html

[codefromthecrypt]

ps LGTM!

[spencergibb]

Closed via 9345553