Conditional registration of @ConfigurationProperties bean

[chrylis]

I have an outstanding SO question that I don't think is supported as a use case as of 1.2.1. Essentially, I would like to use the functionality provided by @ConditionalOnProperty along with the type-safe @ConfigurationProperties. Currently, Spring Boot registers the properties bean regardless of whether any of the properties listed on it exist, so it's impossible to use @ConditionalOnBean(MyConfigProps.class) (I just get a bean with all null fields).

I would like either a way to suppress registration of an "empty" properties bean or a condition that matches only if the bean of the specified @ConfigurationProperties class exists.

Example:

@ConfigurationProperties(prefix = 'my.service')
class ServiceProps {
    String apiKey
}

@Configuration
@ConditionalOnConfigurationProperties(ServiceProps.class)
// or @ConditionalOnBean(ServiceProps.class)
class MyServiceAutoConfig {
    @Autowired
     ServiceProps serviceProps

    @Bean MyService myService() // ...
}

[chrylis]

This is tangentially related to #2282.

[dsyer]

Can't you do this:

@Bean
@ConfigurationProperties('my.service')
@ConditionalOnWhatever
public ServiceProps serviceProps() { return new ServiceProps(); }

[chrylis]

The issue is specifically that @Conditional. It would have to duplicate the information (e.g., list of property names) inside ServiceProps. I'd like to have a standard condition that matches if/unless a typed @ConfigurationProperties gets populated instead of having to list the property names in the annotation.

[dsyer]

I'm not sure I understand the use case yet. We often use a single "enabled" flag to switch a feature on. Is that the sort of thing?

[chrylis]

Sort of, except that if the properties are present, I don't understand the purpose of a separate enable property; it seems like duplication to me. The use case is the exact same as for @ConditionalOnProperty, just wanting to make use of the type-safe config object instead.

[snicoll]

I think that #2282 is a better take at this issue.

If I understand what you're saying, the @ConfigurationProperties annotated pojo should be "injected" only if (at least) one of its property is set. And then use that to enable a behaviour in auto-configuration. I think it's a bit vague to say that "if one property of that pojo is set then do X" and I really like the explicit "enabled" flag as it reads quite well in auto-configuration.

The other problem is when you want to disable the auto-config. Let's assume that you have configured tons of properties for that POJO. With your system, you'll have to comment these out instead of just adding a xyz.enabled=false property. Assume now you have defined those properties in a separate configuration file that is enabled by a profile or something. Now you have to touch that file to disable the behaviour.

My point is that the separate enabled property is extremely useful. If we can agree on that, then #2282 is actually a duplicate of this issue. Does that make sense?

[chrylis]

I can see the multiple-properties-merge issue, and looking at the enabled flag as perhaps more useful as a "disabled" flag makes sense.

What about a @Condition something like this:

Class<@ConfigurationProperties> value;
String enableProperty default "enabled";

(I think that #2282 and this one are both distinct flawed approaches at the same general goal, which seems to be something like this.)

[snicoll]

I am sorry, I didn't get your example.

[chrylis]

I mean an @Conditional annotation with properties something like that, so that by default it will check the enabled property on an @ConfigurationProperties object (so no configuration required for the usual case of prefix.enabled).

[snicoll]

Oh, interesting.

[longfeizheng]

@Configuration
@EnableConfigurationProperties(ServiceProps .class)
public class CoreConfig {

}