Customizing Spring Boot Auto Configuration

Hello friends!!! Once again lets us discuss one of the important topics for spring boot is customizing spring boot autoconfiguration. As all we know that  Freedom of choice is an awesome thing. If you like PIZZA so you have many choices to select your favorite PIZZA like PAN PIZZA, PIZZA with cheese bust, pizza with different different tops yummy :). Now friends please come to our discussion, here we’re going to look at two ways to influence auto-configuration: explicit configuration overrides and fine-grained configuration with properties.
Overriding auto-configured beans
Spring Boot auto-configuration attempts to automatically configure your Spring application based on the jar dependencies that you have added. If you can get what you need without it then why would you do extra work, writing and maintaining extra configuration code, but sometimes there are many cases Spring Boot auto configuration is not good enough. For example one of the cases is when you’re applying security to your application. Security in your application is one of major concern so it is not single fit for all because there are decisions around application security that Spring Boot has no business making for you even though Spring Boot provides auto configuration for some basic spring security things.
For securing the application:
Just adding Spring Security Starter to add spring security auto configuration to the application. In gradle add following line to build.gradle file.
In Maven add following dependency for spring security starter.
That’s it! Rebuild your application and run it. It’s now a secure web application! The security starter adds Spring Security to the application’s classpath. With Spring Security on the classpath, auto-configuration kicks in and a very basic Spring Security setup is created. When open this application browser basic authentication is needed then user name is “user” and password is printed in logs.
Custom security configuration in the application
Basic default configuration probably is not fit for your application because unlike authentication page and password is printed in the logs. That is why you will prefer customized security configuration in the application. For overriding default spring boot auto configuration just writing explicit XML based or Java based configuration in the application this means writing a configuration class that extends WebSecurityConfigurerAdapter.
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    UserRepository userRepository;
    protected void configure(HttpSecurity http) throws Exception {
       protected void configure(
          AuthenticationManagerBuilder auth) throws Exception {
       .userDetailsService(new UserDetailsService() {
       public UserDetails loadUserByUsername(String username)
                  throws UsernameNotFoundException {
           return userRepository.findUserName(username);
SecurityConfig is a very basic Spring Security configuration. Even so, it does a lot of what we need to customize security of the application.
Configuring with external properties
Spring Boot allows you to externalize your configuration so you can work with the same application code in different environments. You can use properties files, YAML files, environment variables, Java system properties, JNDI and command-line arguments to externalize configuration. Spring Boot offers over 300 properties for auto configuration of beans in the application.
Let’s see one of property when you start the application one banner is printed at log screen. So you can disable that banner by setting property to false.
There are following ways to setting up this property when we run the application
Command Line Parameters:
$ java -jar myapp-0.0.1-SNAPSHOT.jar

Setting in “” property file:
Create a YAML file named “application.yml”:
         show-banner: false
Setting property as an environment variable:
$ export spring_main_show_banner=false
Note: the use of underscores instead of periods and dashes, as required for environment variable names.
There are, in fact, several ways to set properties for a Spring Boot application. Spring Boot uses a very particular PropertySource order that is designed to allow sensible overriding of values. Properties are considered in the following order:
  1. @TestPropertySource annotations on your tests.
  2. Command line arguments.
  3. Properties from SPRING_APPLICATION_JSON (inline JSON embedded in an environment variable or system property)
  4. ServletConfig init parameters.
  5. ServletContext init parameters.
  6. JNDI attributes from java:comp/env.
  7. Java System properties (System.getProperties()).
  8. OS environment variables.
  9. A RandomValuePropertySource that only has properties in random.*.
  10. Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants)
  11. Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants)
  12. Application properties outside of your packaged jar ( and YAML variants).
  13. Application properties packaged inside your jar ( and YAML variants).
  14. @PropertySource annotations on your @Configuration classes.
  15. Default properties (specified using SpringApplication.setDefaultProperties)
As for the and application.yml files, they can reside in any of four locations:
  1. Externally, in a /config subdirectory of the directory from which the application is run
  2. Externally, in the directory from which the application is run
  3. Internally, in a package named “config
  4. Internally, at the root of the classpath
Again, this list is in order of precedence. That is, an file in a /config subdirectory will override the same properties set in an file in the application’s classpath.
Also, I’ve found that if you have both and application.yml side by side at the same level of precedence, properties in application.yml will override those in
Spring Boot auto-configuration attempts to automatically configure your Spring application based on the jar dependencies that you have added. You should only ever add one @EnableAutoConfiguration annotation.

Gradually replacing auto-configuration
Auto-configuration is noninvasive, at any point you can start to define your own configuration to replace specific parts of the auto-configuration. For example, if you add your own DataSource bean, the default embedded database support will back away.
Disabling specific auto-configuration
Thymeleaf templates are cached by default that is why changes is never replicate unless you restart the application. You can disable Thymeleaf template caching by setting spring.thymeleaf.cache to false.
Using command-line argument:
$ java -jar myapp-0.0.1-SNAPSHOT.jar --spring.thymeleaf.cache=false
Using application.yml file
          cache: false
You’ll want to make sure that this application.yml file doesn’t follow the application into production.
Using environment variable:
$ export spring_thymeleaf_cache=false
Others template caching can be turned off for Spring Boot’s other supported template options by setting these properties:
  • spring.freemarker.cache (Freemarker)
  • spring.groovy.template.cache (Groovy templates)
  • spring.velocity.cache (Velocity)
By default embedded server for spring boot application is tomcat with port 8080. It is fine in case of single application running but it will be become problem in case run multiple applications simultaneously. If all of the applications try to start a Tomcat server on the same port, there’ll be port collisions starting with the second application.
So to prevent these collisions of port we need to do is set the server.port property.
If this is a one-time change, it’s easy enough to do this as a command-line argument:
$ java -jar myapp-0.0.1-SNAPSHOT.jar --server.port=8181
For permanent port change use application.yml:
     port: 8000
By default, Spring Boot configures logging via Logback ( to log to the console at INFO level.
For Maven builds, you can exclude Logback by excluding the default logging starter transitively resolved by the root starter dependency:
In Gradle, it’s easiest to place the exclusion under the configurations section:
configurations {
all*.exclude group:'org.springframework.boot',
With the default logging starter excluded, you can now include the starter for the logging implementation you’d rather use. With a Maven build you can add Log4j like this:
In a Gradle build you can add Log4j like this:
For full control over the logging configuration, you can create a logback.xml file at the root of the classpath (in src/main/resources). Here’s an example of a simple logback.xml file you might use:
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
<logger name="root" level="INFO"/>
<root level="INFO">
<appender-ref ref="STDOUT" />
To set the logging levels, you create properties that are prefixed with logging.level, followed by the name of the logger for which you want to set the logging level.

        root: WARN
                      security: DEBUG

Now suppose that you want to write the log entries to a file named MyApp.log at /opt/logs/. The logging.path and logging.file properties can help with that:

     path: /opt/logs/
     file: MyApp.log
         root: WARN
              security: DEBUG

By default, the log files will rotate once they hit 10 megabytes in size.


You can also change name of logger configuration file name i.e. you can change name of file logback.xml to log-config.xml by setting the property logging.config in property file or YML file.


application.yml: if you’re using a MySQL database, your application.yml file might look like this

           url: jdbc:mysql://localhost/dojdb
           username: root
          password: root

Specify driver name for database with property spring.datasource
.driver-class-name property as follows

           url: jdbc:mysql://localhost/dojdb
           username: root
          password: root
         driver-class-name: com.mysql.jdbc.Driver

Using JNDI for DataSource:
By using property spring.datasource.jndi-name

            jndi-name: java:/comp/env/jdbc/dojDBDS

Type-safe Configuration Properties
If you are working with multiple properties or your data is hierarchical in nature then sometimes it may be problem in configuration properties. Spring Boot provides an alternative method of working with properties that allows strongly typed beans to govern and validate the configuration of your application.

For example:

public class DatabaseSettings {

    private String dbname;

    private String dburl;

    // ... getters and setters


The @EnableConfigurationProperties annotation is automatically applied to your project so that any beans annotated with @ConfigurationProperties will be configured from the Environment properties. The @ConfigurationProperties annotation won’t work unless you’ve enabled it by adding @EnableConfigurationProperties in one of your Spring configuration classes. This style of configuration works particularly well with the SpringApplication external YAML configuration:

    dbname: dojdb
    dburl: jdbc:mysql//

# additional configuration as required

To work with @ConfigurationProperties beans you can just inject them in the same way as any other bean.

public class UserService {
    private DatabaseSettings connection;
    public void openConnection() {
        Server server = new Server();

It is also possible to shortcut the registration of @ConfigurationProperties bean definitions by simply listing the properties classes directly in the @EnableConfigurationProperties annotation:

public class DBConfiguration {

Using @ConfigurationProperties for outside beans:
We can use @ConfigurationProperties for beans which either outside from the application or not in your control. Let‘s see below

@ConfigurationProperties(prefix = "foo")
public FooComponent fooComponent() {

Any property defined with the foo prefix will be mapped onto that FooComponent bean in a similar manner as the DatabaseSettings example above.

Note: Biding Property in Spring Boot
It’s also worth noting that Spring Boot’s property resolver is clever enough to treat camel-cased properties as interchangeable with similarly named properties with hyphens or underscores. In other words, a property named database.dbName is equivalent to both database.db_name and database.db-name. And also DATABASE_DB_NAME as environment variable in OS.

@ConfigurationProperties Validation
Spring Boot will attempt to validate external configuration, by default using JSR-303 (if it is on the classpath). You can simply add JSR-303 javax.validation constraint annotations to your @ConfigurationProperties class:

public class DatabaseSettings {
    private String dbName;
    private String dbUrl;
    // ... getters and setters

Configuring with profiles
When applications are deployed to different runtime environments, there are usually some configuration details that will differ. The details of a database connection, for instance, are likely different in a development environment than in a quality assurance environment, and different still in a production environment.

public class ProductionConfiguration {
    // ...

The @Profile annotation used here requires that the “production” profile be active at runtime for this configuration to be applied. If the “production” profile isn’t active, this configuration will be ignored and applied any default auto configuration.

Activate profiles:
Profiles can be activated by setting the property using any of the means available for setting any other configuration property. For example, you could activate the “production” profile by running the application at the command line like this:

$ java -jar MyApp-0.0.1-SNAPSHOT.jar --

Or you can add the property to application.yml:

        active: production

Profile-specific properties:
If you’re using to express configuration properties, you can provide profile-specific properties by creating additional properties files named with the pattern “application-{profile}.properties”. Profile-specific properties are loaded from the same locations as standard, with profile-specific files always overriding the non-specific ones irrespective of whether the profile-specific files are inside or outside your packaged jar.

For Example the development configuration would be in a file named and contain properties for verbose, console written logging:


But for production, would configure logging to be at WARN level and higher and to write to a log file:


Multi-profile YAML documents:
You can specify multiple profile-specific YAML documents in a single file by using a spring.profiles key to indicate when the document applies. For example:

        root: INFO
    profiles: development
         root: DEBUG
      profiles: production
      path: /opt/
      file: MyApp.log
          root: WARN

As you can see, this application.yml file is divided into three sections by a set of triple hyphens (—). The second and third sections each specify a value for spring .profiles. This property indicates which profile each section’s properties apply to.

The properties defined in the middle section apply to development because it sets spring.profiles to “development”. Similarly, the last section has spring.profiles set to “production”, making it applicable when the “production” profile is active.

The first section, on the other hand, doesn’t specify a value for spring.profiles. Therefore, its properties are common to all profiles or are defaults if the active profile doesn’t otherwise have the properties set.

Customizing error pages
Spring Boot offers this “whitelabel” error page by default as part of auto-configuration. The default error handler that’s auto-configured by Spring Boot looks for a view whose name is “error”. The easiest way to customize the error page is to create a custom view that will resolve for a view named “error”.

Ultimately this depends on the view resolvers in place when the error view is being resolved. This includes

  • Any bean that implements Spring’s View interface and has a bean ID of “error” (resolved by Spring’s BeanNameViewResolver)
  • A Thymeleaf template named “error.html” if Thymeleaf is configured
  • A FreeMarker template named “error.ftl” if FreeMarker is configured
  • A Velocity template named “error.vm” if Velocity is configured
  • A JSP template named “error.jsp” if using JSP views

Spring Boot Auto configuration do almost configuration for your application. When autoconfiguration doesn’t fit your needs, Spring Boot allows you to override and fine-tune the configuration it provides.

Happy Spring Boot Learning!!!