Spring Auto-Configuration
What is Auto-Configuration and why we need it
Configuration and Auto-Configuration
Configuration is the process of composing the dependency injection context (IoC) of Spring. This is typically done by a combination of using stereotype annotations like @Service and configuration classes (using the stereotype annotation @Configuration). Configuration solves the task to compose building blocks based on the specific requirements of the application.
With Spring-Boot this process is enhanced by Auto-Configuration. Auto-Configuration basically uses the same mechanics. Its purpose is to reduce the amount of configuration that needs to be manually created. While configuration is usually part of the application, Auto-Configuration gets shipped with libraries.
Why do we need Auto-Configuration?
Auto-Configuration is an important tool to improve the developer experience of libraries. This has mainly two reasons:
Reduce the amount of work to integrate with a library
This is the obvious reason. Many aspects that require configuration inside a library are usually much better understood by the maintainer of the library and it is a huge ask for the user of the library to understand all of the internals to get the configuration correct. E.g. if using Spring-Security to implement OAuth 2.0, it should be enough to decide that we want Spring-Security to configure an OAuth 2.0 scenario rather than adding the different components responsible for token validation manually.
In addition this is also pretty efficient, as the recurring task of configuring the IoC for OAuth 2.0 only needs to be solved once instead of in all applications.
Ongoing Maintenance
Not immediately visible, but likely even more important is the role Auto-Configuration plays in application maintenance. Over time, the way a library works and the set of supported features will naturally change. For the implementer of the library, that will likely mean that components and the way they need to be combined change. Without Auto-Configuration this means that users will have to change their configuration. In order to do that, library maintainers will have to provide extensive documentation as well as migration guides. Users have to understand what changed and how that affects their specific use case, considering all differences compared to the examples provided by the library.
Auto-Configuration allows the library maintainer to encapsulate this complexity and provide a library that still behaves as the user expects. New features and improvements can take effect immediately or only on explicit activation, depending on what seems most appropriate.
Get Christian Frommeyer’s stories in your inbox
Join Medium for free to get updates from this writer.
This is a classical win-win scenario. The owners of the library get more freedom in terms of changes they want to implement, they even might be able to deprecate old versions quicker, as upgrading is easier. Users of the library get easier upgrade paths and can concentrate on their own domain. Security vulnerabilities can be addressed faster and new features are easily accessible.
Properties of Spring Auto-Configuration
In this section, I’d like to highlight some features that Springs Auto-Configuration provides, that I deem crucial to unlock its full potential.
No code Auto-Configuration
If you have created a Spring-Boot service, you likely realised the concept of -starter libraries provided by Spring-Boot. These allow adding a feature simply by adding the dependency. This is the lowest possible hurdle to get started, as we will have to configure the dependency anyway. No additional code is required to e.g. fire up an embedded web server, configure basic security and observability. Many features can even be controlled by just adding some properties in the application.yaml file.
Transparent backout to allow customization
One issue complex frameworks need to solve is to allow users to change the default behaviour to solve specific use cases. Ideally this doesn’t require re-implementation of a whole feature or removing conflicting libraries. Spring Auto-Configuration solves this by allowing to override beans with custom implementations. The default implementation in this case will just not be created and the custom implementation will be used instead. Everything else is still provided by the Auto-Configuration.
Reacting to the surrounding configuration
Spring Auto-Configuration provides many (even customizable) ways to react to the surrounding configuration. It’s e.g. possible
- to detect whether the application is running in a traditional thread per request mode or in a reactive (spring-webflux) mode. Libraries can make use of this to add the correct implementation without requiring the user to understand what needs to be implemented differently.
- to adapt to a certain logging or data-base provider. Libraries can react to what’s available on the class-path and use this information to decide on their internal configuration.
- using configuration values allows not only to add additional configuration, but also to augment the meaning of existing configuration.
- use Spring-Boot Failure Analyzers to point developers to frequent issues in integrating a library.
