Spring-boot: Why @EnableAutoConfiguration not has an `include` attribute?

[e7h4n]

I know @EnableAutoConfiguration annotation has a exclude attribute to kick specified autoconfiguration away, but I want to get a more stronger controllability of auto configuration, a white list to specify autoconfigurations which I want to use _explicitly_. So I wonder why spring boot do not allow me to do this, do I use spring boot in a wrong way?

[snicoll]

It all depends what the problem is for you with the _default_ setup. An auto-configuration is supposed to back-off or not kick in at all so having them being processed is the right way to go IMO.

In corner cases or specific circumstances, you may want to disable an auto-configuration explicitly: that's the reason why the exclude flag exists. Why would you need an include flag anyway? If you want to restrict the number of auto-configurations that kick in, you also need to know them. And the whole point is that you shouldn't have to know them except for such corner cases.

Why would you want to list them _explicitly_?

[e7h4n]

@snicoll Auto configuration is an implicit way to put other beans into your application context, it maybe be a problem.

Imagine that, a strange AutoConfiguration is suddenly enabled and inject some beans because your dependency pulled a class which hits a @ConditionalOnClass, it's annoying, especially the wired AutoConfiguration is in a dark corner of some 3rd-party module. This makes the auto configuration unreliable.

To avoid this, I must know much more details of my dependencies (yes, RTFS), and do more checks of auto configuration report when I add 3rd-party module, or after edit application.properties (because @ConditionalOnProperty). This's will be a nightmare for a large team, or a large production.

So I want a effective way to take back control from 3rd-party module to the main application, like the @Import annotation, is explicit, easier, controllable and reliable.

[wilkinsona]

@perfectworks, if you want precise control over the configuration, you can use @Import and import the *AutoConfiguration classes that you care about. We do this in many of our integration tests.

[e7h4n]

@wilkinsona Could I use @Import without @EnableAutoConfiguration ?

[snicoll]

@wilkinsona that's true but do not forget that you'll lose some feature when you do that. In particular, auto-configuration ordering won't be processed automatically (AutoConfigureOrder). While this technique works for us in integration tests, I'd not advertize that for "apps". We may improve what @EnableAutoConfiguration does behind the scenes in the future.

@perfectworks that's the whole point. Instead of putting @EnableAutoConfiguration that is going to basically discover the available auto-configs, you provide them yourself explicitly. Very useful in integration tests indeed!

[e7h4n]

@snicoll Yes it's works. :+1: I think this issue can be closed.

[Geniy00]

Hi All. I have a question related to the topic.

I have a very big project, where I'd like to use my custom AutoConfigurations.
But I don't like to use any from org.springframework.boot:spring-boot-autoconfigure (I mean package org.springframework.boot.autoconfigure.*)

Is it possible to exclude them all?

The problem is that I got a lot of errors and circular dependencies after adding @EnableAutoConfiguration. And I can't see Auto-configuration report because the application can be started due to all those errors.

[wilkinsona]

@Geniy00 That's not possible at the moment. I've opened #3859 to discuss a possible solution.