One of the common things on web application development is to initialize or invoke a piece of code at the start up of the application. If you are developing a traditional Java web application, the startup logic can be mentioned in the ServletContextListener. Spring also offers very convenient way of invoking the events at the different stages of the application life cycle. I have earlier explained about the EventListener in Spring 4 and ContextRefreshedEvent.

This tutorial guides you through on implementing the start up event listeners when writing the spring boot applications.

Spring Framework Events

The following are the list of spring framework events that can be triggered at the spring context initialization.

• ContextRefreshedEvent : This event is triggered upon spring context start and refresh events. This events is most commonly used for initializing the data at the start up.
• ContextStartedEvent : This event is triggered upon spring context start. The main difference between ContextRefreshedEvent  is that this event is invoked only at the start and not on the refresh of context.
• ContextStopedEvent : This event is triggered when spring context is stopped.
• ContextClosedEvent : This event is triggered when spring context is closed.

Spring Boot Events Example

I have written a simple example that demonstrates how to publish an event at the spring boot application startup. I have registered ApplicationListener for listening to the ContextRefreshedEvent. Let’s look at the code for more understanding.

I have uploaded the complete source code for the download.

ContextRefreshedListener.java

[code lang=”java”]
package net.javabeat.spring.boot.example.util;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationListener;
import org.springframework.context.event.ContextRefreshedEvent;
import org.springframework.stereotype.Component;

@Component
public class ContextRefreshedListener implements ApplicationListener<ContextRefreshedEvent> {
private SampleEvent sampleEvent;

@Autowired
public void setSampleEvent(SampleEvent sampleEvent) {
this.sampleEvent = sampleEvent;
}

public void onApplicationEvent(ContextRefreshedEvent contextRefreshedEvent) {
System.out.println("Context Refreshed");
sampleEvent.setEventFired(true);
}
}
[/code]

SampleEvent.java

[code lang=”java”]
package net.javabeat.spring.boot.example.util;

import org.springframework.stereotype.Component;

@Component
public class SampleEvent {
private Boolean eventFired = false;

public Boolean getEventFired() {
return eventFired;
}

public void setEventFired(Boolean eventFired) {
this.eventFired = eventFired;
}
}
[/code]

Application.java

[code lang=”java”]
package net.javabeat.spring.boot.example;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ConfigurableApplicationContext;

import net.javabeat.spring.boot.example.util.SampleEvent;

@SpringBootApplication
public class Application {
public static void main(String[] args) {
ConfigurableApplicationContext ctx = SpringApplication.run(Application.class, args);
SampleEvent bean = ctx.getBean(SampleEvent.class);
System.out.println("Is Event Fired : " + bean.getEventFired());
}

}
[/code]

pom.xml

[code lang=”xml”]
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>net.javabeat</groupId>
<artifactId>boot</artifactId>
<packaging>war</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>boot</name>
<url>http://maven.apache.org</url>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.3.3.RELEASE</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
</dependencies>
<build>
<finalName>boot</finalName>
</build>
</project>
[/code]

Output for the above program is:

[code]
2016-03-18 22:25:15.783 INFO 6636 — [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup
Context Refreshed
2016-03-18 22:25:15.972 INFO 6636 — [ main] s.b.c.e.t.TomcatEmbeddedServletContainer : Tomcat started on port(s): 8080 (http)
2016-03-18 22:25:15.980 INFO 6636 — [ main] n.j.spring.boot.example.Application : Started Application in 2.699 seconds (JVM running for 3.003)
Is Event Fired : true
[/code]

Download Source Code

[wpdm_package id=’23309′]

The main reason why Spring Boot is developed by Spring community is to simplify the packaging and deploying your spring applications to production. Keeping with that in mind, spring boot assumes all the default values loaded at startup is optimized for the production ready application. For example, caching of Thymeleaf templates are enabled by default which improves the performance in the production. However, these settings must be disabled for the development environment to test the applications effectively when ever you make the changes in the code.

This tutorial walks you through the various features available in the devtools module.

The table of contents for this tutorial:

1. What is Spring Boot DevTools?
2. Auto Restart
   1. Exclude Resources
   2. Disable Restart
   3. Watch Additional Paths
3. Default Properties
4. Live Reload
5. Summary

What is Spring Boot devTools?

Spring Boot 1.3 ships with new module spring-boot-devtools. The primary goal of this module is to improve the development speed by enabling some of the key features that are important during the development phase of your project. This tutorial explains how to use spring boot devtools and different options available as part of the spring boot devtools.

You can include this module to your spring boot application by adding the following maven snippet:

[code lang=”xml”]
&lt;dependencies&gt;
&lt;dependency&gt;
&lt;groupId&gt;org.springframework.boot&lt;/groupId&gt;
&lt;artifactId&gt;spring-boot-devtools&lt;/artifactId&gt;
&lt;/dependency&gt;
&lt;/dependencies&gt;
[/code]

For Gradle build:

[code]
dependencies {
compile("org.springframework.boot:spring-boot-devtools")
}
[/code]

Once you have added the above dependency to the spring boot application, it will add lot of spring-boot-devtools features.

Auto Restart

Greg L. Turnquist is correct, the real gem from spring boot is coming out. If you are a developer, you are well aware that how much important to auto load the application when there is some changes in the code. It is one of the main feature that lacks spring boot application since it’s inception. But, the devtools features brings the auto restart of the application on any code changes.

If there is any changes to the classpath, the application will automatically restart to effect the new changes. This is quite fast when I have tested in my local system. Spring boot team have managed two classloaders, one is for loading the project specific class files (which changes frequently) and another one is for third party libraries.

For any changes to the project files, spring boot restart a classloader that loads the project specific class files. Since it is not loading the entire application, the speed of the restart is much faster. If you have any experience, please write it in the comments section.

Exclude Resources

When auto restart is enabled, all the files in the classpath will be monitored for the changes. But, if there is any changes to the static files like templates, css, etc. not require any server restart for loading the resources. To overcome that issue, you can easily exclude the files under certain path from the auto restart option. You could add the resources that you don’t want to load on changes:

[code]
spring.devtools.restart.exclude=/META-INF/resources
[/code]

Disable Restart

Also you can disable the restart option by add the spring.devtools.restart.enabled property to the application.properties file as follows:

[code]
spring.devtools.restart.enabled=false
[/code]

The good thing is that when you set this property, immediately it takes effect and you need not manually stop and start the spring boot application.

Watch Additional Paths

By default, spring boot application performs automatic restart only when the resources under classpath changes. But, if you want to enable the auto restart for the resources outside the classpath, then you can use the following property to  add the additional paths on auto restart.

[code]
spring.devtools.restart.additional-paths=/src
[/code]

Default Properties

Spring boot supports multiple cache libraries for improving the performance. By default template caching is enabled by spring boot for improving the performance. However, this is a counter productive at the development time. Prior to spring boot 1.3.0, developers has to update the application.propertries file for disabling the cache.

Now it is changed. By adding the spring-boot-devtools, the following template caches are disabled by default:

• spring.thymeleaf.cache=false
• spring.freemarker.cache=false
• spring.groovy.template.cache=false
• spring.velocity.cache=false
• spring.mustache.cache=false

These configurations are updated in the file DevToolsPropertyDefaultsPostProcessor.java

Live Reload

spring-boot-devtools includes the embeded LiveReload server. Whenever there is any changes to the server, the browser will be trigger for the refresh. You can get the free extension for the live reload here.

If you don’t want to start the LiveReload server on the start up, please add the following entry to the application.properties:

[code]
spring.devtools.livereload.enabled=false
[/code]

Note that you will be able to run only one LiveReload server at a time, if you are running multiple applications in your IDE, the first one will have the LiveReload enabled.

You can see the LiveReload server startup message at the console. If you set the spring.devtools.livereload.enabled property to false, then the server will not be started when spring boot initializes the application.

 Summary

I hope this tutorial provides good information on what is spring boot devtools, what are the features in the devtools and how to use them. At high level, it is an additional module to the spring application for improving the productivity. Especially, the auto restart feature is very useful at the development time. If you have any questions, please write it in the comment section.

Thank you for reading  my blog!! Happy Reading!!

 

This tutorial highlights the new features added as part of the spring boot 1.3.0 for caching support. Caching has been supported by spring boot, but there is no auto configuration option for the caching in spring boot until now. The new Spring Boot release 1.3.0 has introduced the following features that makes easier to use the caching within spring boot powered applications:

1. Auto configuration is supported for the caching.
2. Spring boot actuator adds caching metrics to the /metrics endpoint.

In this tutorial, I have explained the above two new features as part of the caching support in spring boot applications. I have used the same example application used as part of the Spring Data Tutorial and added the caching implementation (ehcache) on top of the same example. The revised implementation of the example application I have uploaded at the end of this tutorial for your download. This tutorial just explains the caching specific pieces. Hope that helps. If you have any questions, please write it in the comments section.

Caching Auto Configuration

Spring Boot simplifies the configuration of caching implementation with auto-configuration support. If you are not familiar with the word auto-configuration, here is the definition: Auto-configuration in spring boot searches the libraries and configuration files in the classpath and initialize the required dependency beans at the application start up. This eliminates the need for manually configuring the beans to instantiate and ready for the use.

For example: If you have the ehcache.xml in the classpath and you have the ehcache 2.x libraries present, then spring boot will configure the ehcache as the caching implementation for your application by initializing the cache managers for ehcache.

Prior to the auto-configuration, you would require the following lines of code in the spring boot configuration file:

[code lang=”java”]
@SpringBootApplication
@EnableCaching
public class MyBooks {
@Bean
public CacheManager cacheManager() { …}

…
}
[/code]

With Spring Boot 1.3.0, the last step of adding the bean definitions also bean eliminated. The following are the steps to enable ehcache for your application:

1. Add @EnableCaching annotation in the spring boot configuration class. This annotation is the indicator for enabling the caching mechanism in your application.
2. Next step is to add the required libraries in the classpath. If you are using the ehcache as the cache implementation, then add the dependency to the POM.xml file.
3. Next step is to add the configuration file for the cache provider. If you are using the ehcache, the add the ehcache.xml at the root of the classpath.

Spring boot tries to detect the following cache providers in the order given below:

1. Generic
2. EhCache 2.x
3. Hazelcast
4. Infinispan
5. JCache (JSR-107)
6. Redis
7. Guava
8. Simple

If the spring boot finds more than once cache provider in the classpath, in that case the cache provider must be explicitly specified. Add the following entries to the application.properties file:

[code]
# Only necessary if more than one provider is present
spring.cache.ehcache.provider=net.sf.ehcache.CacheManager
spring.cache.ehcache.config=classpath:config/another-config.xml
[/code]

Caching Metrics in Spring Boot Actuator

/metrics endpoint exposes the various metrics about the running application. Spring Boot 1.3.0 adds the details about the cache implementation also as part of the /metrics endpoint. The following details are exposed:

• The current size of the cache (cache.xxx.size)
• Hit ratio (cache.xxx.hit.ratio)
• Miss ratio (cache.xxx.miss.ratio)

Note: The cache metrics may be different for each provider. So, you have to check the provider documentation for more details about how the metrics about hit / miss ratios are exposed by the provider. When I have tried the sample application, I could not get the hit / miss ratio for ehcache, it looks there is some issue at present. You can see the size of the cache display in the below screenshot. I will update the tutorial with more details.

Example Application

Now we review the example application that supports the auto-configuration for caching and exposes the cache metrics. As I have told, this example is the extension of the Spring Data Tutorial. Refer the spring data tutorial if you want to understand how spring data works.

Here is the updated SpringBootApplication.java. The only update is @EnableCaching annotation.

[code lang=”java”]
@Configuration
@SpringBootApplication
@EnableJpaRepositories
@EnableCaching
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}

}
[/code]

You have to enable caching for the one method. The similar way you can do for other methods. If you are looking for more details about the spring caching abstraction, please read our spring cache tutorial.

[code lang=”java”]
@Cacheable ("books")
public Book findOne(long id);
[/code]

Just add ehcache.xml file in the root of the classpath:

[code lang=”xml”]
<?xml version="1.0" encoding="UTF-8"?>
<ehcache>
<diskStore path="java.io.tmpdir" />
<defaultCache maxElementsInMemory="10" eternal="false" timeToIdleSeconds="120" timeToLiveSeconds="120" overflowToDisk="true" />
<cache name="books" maxElementsInMemory="50" eternal="false" overflowToDisk="true" timeToIdleSeconds="0" timeToLiveSeconds="86400" />
</ehcache>
[/code]

The project structure would look like this:

When spring boot initializes the ehcache, you would see the following messages in the console which confirms the initialization of ehcache by the example application.

[code]
Bean ‘org.springframework.cache.annotation.ProxyCachingConfiguration’ of type [class org.springframework.cache.annotation.ProxyCachingConfiguration$$EnhancerBySpringCGLIB$$ce3ea348] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
Bean ‘org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration’ of type [class org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration$$EnhancerBySpringCGLIB$$866a36c] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
Bean ‘spring.cache.CONFIGURATION_PROPERTIES’ of type [class org.springframework.boot.autoconfigure.cache.CacheProperties] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
Bean ‘org.springframework.boot.autoconfigure.cache.CacheManagerCustomizers’ of type [class org.springframework.boot.autoconfigure.cache.CacheManagerCustomizers] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
Bean ‘org.springframework.boot.autoconfigure.cache.EhCacheCacheConfiguration’ of type [class org.springframework.boot.autoconfigure.cache.EhCacheCacheConfiguration$$EnhancerBySpringCGLIB$$f507a8aa] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
Bean ‘ehCacheCacheManager’ of type [class net.sf.ehcache.CacheManager] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
Bean ‘cacheManager’ of type [class org.springframework.cache.ehcache.EhCacheCacheManager] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
cacheAutoConfigurationValidator’ of type [class org.springframework.boot.autoconfigure.cache.CacheAutoConfiguration$CacheManagerValidator] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)
[/code]

Download the Source Code

[wpdm_package id=’22582′]

Summary

The above sections explains you the auto configuration of caching in spring boot applications and how to expose the caching metrics using the spring boot actuator. This tutorial primarily focused on the ehcache implementation, I would add the other caching provider details in future. Stay tune to receive more updates on spring boot caching.

Thank you for reading my blog!! Happy Reading and Have fun!!

In my previous articles for Spring Data JPA, I have used in-memory databases like H2 for persisting data. But, these in-memory databases can not be used for the production. These are only used for the development environment. In this post I will explain the basic configurations for setting up the MYSQL database for your Spring Data JPA and Spring Boot applications.

Here I am going to use the same example used in my previous tutorials. I am just going to replace the database for the sample application. Note that this tutorial uses Spring Boot for deploying the sample application. If you are not using Spring Boot, this may not be much useful to configure your applications.

Here is the required configurations to use MySQL database to your Spring Boot application.

Maven Configurations

In the maven’s pom.xml, you just need to add mysql connector. Once this is added to the classpath, Spring Boot will automatically search for the MySQL configurations and use it.

[code lang=”xml”]
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
</dependency>
[/code]

MySQL Configurations

Next step is to add the MySQL configurations in the application.properties.

[code]
spring.datasource.url=jdbc:mysql://localhost:3306/test
spring.datasource.username=root
spring.datasource.password=admin
spring.datasource.driver-class-name=com.mysql.jdbc.Driver
[/code]

Database Schema / Data

This is only optional for you. If you want to create the tables and load the data at the start up, you have to create schema-mysql.sql and data.sql. The file name of the schema can be either schema-mysql.sql or schema.sql.
schema-mysql.sql

[code]
drop TABLE IF EXISTS book;
create table book(
id int not null primary key,
name varchar_ignorecase(50) not null,
author varchar_ignorecase(50) not null,
price int,
creation_time datetime);
[/code]

I hope in this tutorial you have understood how to use MySQL configurations for spring boot applications. You can download the complete sample application here:
[wpdm_package id=’22582′]

Build Your REST API with Spring - VIDEO Courses

Spring Boot Actuator

You are here to learn about Spring Boot Actuator for collecting metrics about your production grade applications. Spring Boot Actuator is sub-project of Spring Boot and it is one of the nice feature that adds great value to the Spring Boot applications. Lets understand in this tutorial about spring boot actuator and different types of metrics that can be collected using this feature.

• Are you interested in reading more about spring boot, please look at our spring boot tutorials page.

Table of Contents

The sections covered in this post about the Spring Boot Actuator.

1. What is Spring Boot Actuator?
2. How to enable spring boot actuator?
3. Actuator endpoints
4. Customizing endpoints
5. Security
6. Endpoint – Info
7. Endpoint – Dump
8. Endpoint – Health
9. Custom Health Endpoint
10. Endpoint – Metrics
    1. Caching Metrics (Since Spring Boot 1.3.0)
11. Endpoint – Logfile
12. Create custom endpoints
13. List all the endpoints
14. Example application
15. Common exceptions

What is Spring Boot Actuator?

• Spring Boot Actuator is a sub-project / feature that is part of the spring boot framework. It is not a separate framework to be added to your applications.
• Main purpose of this feature is to provide various useful metrics about the applications. It is very helpful in the production environment to check the various metrics like health of your application, configurations, error page, version details, etc.
•  Actuator is supported out of the box within spring boot applications. You just have to add the dependency to enable the actuator. The default configurations are enabled if you are not providing any application specific configurations.
• Actuator makes the metrics are accessed through different endpoints like /error, /metrics, /beans, /info, etc. End points are HTTP URLs that can be accessed through your browser.

How To Enable Spring Boot Actuator?

Please add the following pom.xml entries in your spring boot application.

[code]
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
[/code]

That’s it?. Yes. You have now added the  actuator to your existing application. When you re-start your application, endpoints are enabled for the user access. More detailed configurations and customization of the metrics are explained in the future sections.

Actuator Endpoints

HTTP Endpoints are enabled for accessing the various information about your application. The list of 15 endpoints that are currently supported by spring boot actuator module is:

1. actuator: It is the default endpoint to list the available endpoints exposed to the user. It is enabled only when HATEOAS available in your classpath.
2. autoconfig : Report on auto-configuration details.
3. beans : This endpoint lists all the beans loaded by the application.
4. configprops : This endpoint shows configuration properties used by your application.
5. dump : Performs a thread dump.
6. env : Exposes spring’s properties from the configurations.
7. health : Health of the application.
8. info : Displays application information like version, description, etc.
9. metrics : Metrics about memory, heap, etc. for the currently running application
10. mappings : Displays a list of all @RequestMapping paths.
11. shutdown : This endpoint allows to shutdown the application. This is not enabled by default.
12. trace : Displays trace information for the current application.
13. logfile : Provides access to the configured log files (This feature supported since Spring Boot 1.3.0).
14. flyway : This endpoint provides the details of any flyway database migrations have been applied (This feature supported since Spring Boot 1.3.0).
15. liquibase : This endpoint provides the details of any liquibase database migrations have been applied (This feature supported since Spring Boot 1.3.0).

In the above list, only few are enabled by default. Others are disabled by default for the security reasons. Developers can override the properties to enable them. We will explain the manual configurations in the subsequent sections.

Customizing Endpoints

In the above section, we have listed all the endpoints and the purpose of each endpoints in brief. But, just enabling the endpoints may not be sufficient in most of the real time applications. You would like to update application specific configurations. That can be done through spring boot’s configurations file application.properties.

If you want to understand how the project structure and location of the properties files are in the project, look at the below screen shot of the example project structure.

The most common settings are:

• management.port=8081 – change the port of the actuator endpoints in your server
• management.address=127.0.0.1 –  restrict to run only on localhost
• management.context-path=/details – change the context path for actuator
• endpoints.health.enabled=false – enable or disable the endpoints.

The above are just for the understanding purpose I have listed few configurations.

Security

Most of the times, the details exposed via few of the endpoints are sensitive and requires authorized user to view the details. You can add spring security to secure your endpoints. Just add the dependency, when the spring security files are available in the classpath, it will be automatically configured.

[code lang=”xml”]
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
[/code]

By default, the basic security enabled. This will be enabled for all the endpoints. But, you can disable them by updating the application.properties file and expose the non-sensitive endpoints without security.

The following are the basic entries that are required to configure the security for your spring boot actuator application:

[code]
management.security.enabled=true
security.basic.enabled=true
security.user.name=admin
security.user.password=admin
[/code]

In the above configurations, we are enabling the basic security and providing the user name and password to access the endpoints. When user tries to access the endpoints, there will be pop-up on the browser to authenticate the user with credentials.

Endpoint – Info

• This endpoint helpful for displaying the details of the applications like application name, description, version, etc.
• By default, the endpoint can be accessed using /info
• The default value for sensitive is false. There is no harm in exposing this details as that is common details that has to be exposed to others.

Configuration in application.properties file:

[code]
endpoints.info.id=info
endpoints.info.sensitive=false
endpoints.info.enabled=true
info.app.name=Spring Actuator Example
info.app.description=Spring Actuator Working Examples
info.app.version=0.0.1-SNAPSHOT
[/code]

When you execute the above configurations, you would get the following output in the browser:

[code]
{
"app": {
"version": "0.0.1-SNAPSHOT",
"description": "Spring Actuator Working Examples",
"name": "Spring Actuator Example"
}
}
[/code]

Endpoint – Dump

Thread dumps are important when your application encounters any performance issues. In normal scenarios, you have to request the production server administrator to take the thread dumps at the frequent intervals and send across to you for the analysis. But, that takes lot of time and also you would require the thread dumps only when the actual performance issue arises.

This end point is would offer real benefits to the production applications to get the thread dumps just by accessing the application using browser. It is awesome to see spring boot offers such an excellent features for the production application. Long live spring boot :).

Endpoint – Health

• This endpoint used for knowing the status / health of application whether it is Up or Down.
• If the endpoint is accessed through normal unauthenticated way, it returns simple status message. If accessed through authenticated way, there will be additional details displayed.
• The default value for sensitive is false.
• You can write your custom health indicator to provide additional details to the user. The following are the list of health indication implementation classes available for customization:
  • DiskSpaceHealthIndicator
  • DataSourceHealthIndicator
  • MongoHealthIndicator
  • RabbitHealthIndicator
  • SolrHealthIndicator

The basic configurations for health endpoint is:

[code]
endpoints.health.id=health
endpoints.health.sensitive=true
endpoints.health.enabled=true
[/code]

Custom Health Endpoint

In the above section what we have learnt is how to use the built-in health endpoint. One can extend the HealthIndicator interface and provide their own implementation. CustomHealthCheck is implementing the method health() which is declared in the interface HealthIndicator. When you create a custom class of this type and override the method health(), the default functionality will be overwritten by your custom logic.

Look at the example code:

[code lang=”java”]
@Component
public class CustomHealthCheck implements HealthIndicator {
public Health health() {
int errorCode = 0;
if (errorCode != 1) {
return Health.down().withDetail("Error Code", errorCode).build();
}
return Health.up().build();
}

}
[/code]

The output will be:

[code]
{
"status": "DOWN",
"customHealthCheck": {
"status": "DOWN",
"Error Code": 0
},
"diskSpace": {
"status": "UP",
"free": 195979440128,
"threshold": 10485760
}
}
[/code]

 Endpoint – Metrics

• By default this endpoint is enabled under the HTTP URL /metrics.
• This endpoint used for collecting the details of applications performance like memory, processors, up time, heap size, classes loaded, garbage collection, http sessions, etc.

The example configuration for this endpoint is:

[code]
endpoints.metrics.id=metrics
endpoints.metrics.sensitive=true
endpoints.metrics.enabled=true
[/code]

When you access the endpoint, you would receive the output as in the below screen. This is for the default configurations.

Cache Metrics

• Cache metrics details are added to the metrics endpoint since the spring boot 1.3.0 release.

The newly added metrics details are:

• The current size of the cache cache.xxx.size
• The hit ratio cache.xxx.hit.ratio
• The miss ration cache.xxx.miss.ratio

The hit and miss ration may not be consistent across the cache providers. Because they might have different way of exposing the hit and miss ratios. Please refer their documentation for more details.

By default spring boot actuator supports the caching metrics for EhCache (Also Read : Spring Cache Tutorial), Hazelcast, Infinispan, JCache and Guava. If your caching implementation in your application is not one of the above, then please add the CacheStatisticsProvider bean to support the caching metrics.

If you are interested, please read our in-depth article on caching support in spring boot.

Endpoint – Logfile

• This end point is added from the spring boot 1.3.0 release.

This endpoint will be automatically enabled if logging.path or logging.file properties are configured in the application.properties file. When you access the logile endpoint, this will return the complete log of the application.

Whatever the log file location configured in the environment will be displayed in the browser. This feature is very useful for the production grade applications to check the log files easily through browser. Let’s look at the same log file accessed from the example application.

Custom Endpoint Implementation

Apart from the above default endpoints exposed by spring boot, developers can write their own endpoints by implementing the interface Endpoint. This is useful when you want to expose application details which are an added feature to your application. For example, in this example I have created a custom endpoint to display the server details for the application.

The implementation class would looks like this:

[code lang=”java”]
@Component
public class ServerEndpoint implements Endpoint<List<String>> {

public String getId() {
return "server";
}

public List<String> invoke() {
List<String> serverDetails = new ArrayList<String>();
try {
serverDetails.add("Server IP Address : " + InetAddress.getLocalHost().getHostAddress());
serverDetails.add("Server OS : " + System.getProperty("os.name").toLowerCase());
} catch (Exception e) {
e.printStackTrace();
}
return serverDetails;
}

public boolean isEnabled() {
return true;
}

public boolean isSensitive() {
return false;
}

}
[/code]

• ServerEndpoint class implements Endpoint. Any class of type Endpoint will be exposed as an endpoint in the server
• If you look at the methods, getId(), isEnabled() and isSensitive(), which are the properties that are overridden by the application.properties file.
• invoke() is the important method responsible for writing the message. Here I have written simple message, in real time applications it could involve more complex logic.

When you execute example application, the output will be:

[code]
["Server IP Address : 192.168.1.4","Server OS : windows nt (unknown)"]
[/code]

List All The Endpoints

It is quite useful if you have an endpoint to display all the endpoints in a single web page. There is a built-in endpoint /actuator for this purpose, but you have to add HateOAS in the classpath to enable that feature.

We could write a custom endpoint in the similar way how we have written in the above section to print the endpoints. The following class extends AbstractEndpoint to list all the end points.

Sample implementation is :

[code lang=”java”]
@Component
public class ShowEndpoints extends AbstractEndpoint<List<Endpoint>>{

private List<Endpoint> endpoints;

@Autowired
public ShowEndpoints(List<Endpoint> endpoints) {
super("showEndpoints");
this.endpoints = endpoints;
}

public List<Endpoint> invoke() {
return this.endpoints;
}
}
[/code]

When you implement the above class, there will be a new endpoint “showEndpoints” will be registered and exposed to the users. The output will be:

[code]
[
{
"sensitive": false,
"id": "server",
"enabled": true
},
{
"id": "mappings",
"sensitive": true,
"enabled": true
},
{
"id": "env",
"sensitive": true,
"enabled": true
},
{
"id": "health",
"sensitive": true,
"enabled": true,
"timeToLive": 1000
},
{
"id": "beans",
"sensitive": true,
"enabled": true
},
{
"id": "info",
"sensitive": false,
"enabled": true
},
{
"id": "metrics",
"sensitive": true,
"enabled": true
},
{
"id": "trace",
"sensitive": true,
"enabled": true
},
{
"id": "dump",
"sensitive": true,
"enabled": true
},
{
"id": "autoconfig",
"sensitive": true,
"enabled": true
},
{
"id": "shutdown",
"sensitive": true,
"enabled": false
},
{
"id": "configprops",
"sensitive": true,
"enabled": true
}
]
[/code]

Example Application for Actuator

In this section I have listed all the source code for writing this tutorial from the beginning. There is no other configurations required to run this example application. Note that this example just used actuator feature and not considered any other concept in the spring boot, so I have nore written any Spring MVC controller classes.

How to run this example application?

If you are running this project inside Eclipse or from the maven command, you can run using the following command:

[code]
mvn spring-boot:run
[/code]

The application’s actuator endpoint will be enabled at

[code]
http://localhost:8081/details/
[/code]

Here is the list of source codes.

pom.xml

[code lang=”xml”]
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>javabeat.net</groupId>
<artifactId>spring-boot-actuator-example</artifactId>
<packaging>war</packaging>
<version>0.0.1-SNAPSHOT</version>
<name>spring-boot-actuator-example Maven Webapp</name>
<url>http://maven.apache.org</url>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.2.5.RELEASE</version>
</parent>

<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
</dependencies>
<build>
<finalName>spring-boot-example</finalName>
</build>
</project>
[/code]

Application.java

[code lang=”java”]
package net.javabeat;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.context.annotation.ComponentScan;

@EnableAutoConfiguration
@ComponentScan
public class Application{

public static void main(final String[] args) {
SpringApplication.run(Application.class, args);
}
}
[/code]

ServerEndpoint.java

[code lang=”java”]
package net.javabeat;

import java.net.InetAddress;
import java.util.ArrayList;
import java.util.List;

import org.springframework.boot.actuate.endpoint.Endpoint;
import org.springframework.stereotype.Component;

@Component
public class ServerEndpoint implements Endpoint<List<String>> {

public String getId() {
return "server";
}

public List<String> invoke() {
List<String> serverDetails = new ArrayList<String>();
try {
serverDetails.add("Server IP Address : " + InetAddress.getLocalHost().getHostAddress());
serverDetails.add("Server OS : " + System.getProperty("os.name").toLowerCase());
} catch (Exception e) {
e.printStackTrace();
}
return serverDetails;
}

public boolean isEnabled() {
return true;
}

public boolean isSensitive() {
return false;
}

}
[/code]

ShowEndpoints.java

[code lang=”java”]
package net.javabeat;

import java.util.List;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.actuate.endpoint.AbstractEndpoint;
import org.springframework.boot.actuate.endpoint.Endpoint;
import org.springframework.stereotype.Component;

@Component
public class ShowEndpoints extends AbstractEndpoint<List<Endpoint>>{

private List<Endpoint> endpoints;

@Autowired
public ShowEndpoints(List<Endpoint> endpoints) {
super("showEndpoints");
this.endpoints = endpoints;
}

public List<Endpoint> invoke() {
return this.endpoints;
}
}
[/code]

CustomHealthCheck.java

[code lang=”java”]
package net.javabeat;

import org.springframework.boot.actuate.health.Health;
import org.springframework.boot.actuate.health.HealthIndicator;
import org.springframework.stereotype.Component;

@Component
public class CustomHealthCheck implements HealthIndicator {
public Health health() {
int errorCode = 0;
if (errorCode != 1) {
return Health.down().withDetail("Error Code", errorCode).build();
}
return Health.up().build();
}

}
[/code]

application.properties

[code]
management.port=8081
management.context-path=/details
management.security.enabled=true

security.basic.enabled=true
security.user.name=admin
security.user.password=admin

endpoints.health.id=health
endpoints.health.sensitive=true
endpoints.health.enabled=true

endpoints.metrics.id=metrics
endpoints.metrics.sensitive=true
endpoints.metrics.enabled=true

endpoints.server.id=server
endpoints.server.sensitive=false
endpoints.server.enabled=true

endpoints.info.id=info
endpoints.info.sensitive=false
endpoints.info.enabled=true
info.app.name=Spring Actuator Example
info.app.description=Spring Actuator Working Examples
info.app.version=0.0.1-SNAPSHOT
[/code]

Common Exceptions

This section lists some of the common exceptions you would have encountered if by chance missed any configurations. If you encounter any other hurdles on the way to learn actuator, please post it in the comments section. We will add that in this section.

ContextPath Issues:

If you are seeing the following exception, that means that you are not having the proper context path configured. The context path must start with “/” and must not end with “/”. For example “/details” is correct and “details” is not correct.

[code]
Caused by: java.lang.IllegalArgumentException: ContextPath must start with ‘/ and not end with ‘/’
at org.springframework.boot.context.embedded.AbstractConfigurableEmbeddedServletContainer. checkContextPath(AbstractConfigurableEmbeddedServletContainer.java:103)
at org.springframework.boot.context.embedded.AbstractConfigurableEmbeddedServletContainer. setContextPath(AbstractConfigurableEmbeddedServletContainer.java:91)
at org.springframework.boot.actuate.autoconfigure.EndpointWebMvcChildContextConfiguration $ ServerCustomization.customize(EndpointWebMvcChildContextConfiguration.java:87)
[/code]

Security Exception:

If you are getting the following exception, then probably you have the following entry in your application.properties and not added your spring security dependency in your classpath. Please check your pom.xml and update accordingly to add the spring security JARs on the classpath to resolve this error.

[code]
management.security.enabled=true
[/code]

This is the exception:

[code]
Exception in thread "main" org.springframework.beans.factory.BeanCreationException:
Error creating bean with name ‘managementServerProperties’
defined in class path resource [org/springframework/boot/actuate/autoconfigure/
ManagementServerPropertiesAutoConfiguration.class]: Initialization of bean failed;
nested exception is java.lang.NoClassDefFoundError:
org/springframework/security/config/http/SessionCreationPolicy
at org.springframework.beans.factory.support.
AbstractAutowireCapableBeanFactory.doCreateBean( AbstractAutowireCapableBean Factory.java:547)
Caused by: java.lang.NoClassDefFoundError: org/springframework/ security/config/http/SessionCreationPolicy
at org.springframework.boot.actuate.autoconfigure. ManagementServerProperties$ Security.<init>(ManagementServerProperties.java:95)
at sun.reflect.NativeConstructorAccessorImpl. newInstance0(Native Method)
Caused by: java.lang.ClassNotFoundException: org.springframework. security.config.http. SessionCreationPolicy
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
[/code]

Actuator Video

Here is a short video on how to use actuator by Baeldung in his REST video course:

Conclusion

I hope this tutorial about spring boot actuator would have provided most comprehensive details. I have explained about the basic concepts on actuators, endpoints, list of endpoints, creating custom endpoints, health check,metrics (also caching metrics introduced in spring boot 1.3.0) and provided a complete working example application for spring boot actuator.

If you have faced any challenges on using the actuator feature in spring boot, please write to me in the comments section. I am happy to resolve your issues.

Thank you for visiting my blog. Happy Reading!!

Logging is an important part of any application. Checking the logs is the first step towards debugging any issue. So logging the right information is important. At the same time logging too much can lead to bloated log file in turn using lot of disk space. In some applications developers use synchronous logging which can impact the application’s performance. Logging libraries like Logback, Log4j2 provide async logging.

• Also Read : Spring Boot Tutorials

Spring Boot provides great support for logging and provides lot of hooks to configure the same. In this article we are going to see the default support for logging in Spring Boot, then use the hooks i.e the spring properties to configure the logging. At the end of this article, you will be familiar with the logging configuration in spring boot applications.

Create Spring Boot Project using Maven

Let us first create a simple maven project and update the pom.xml with the below code:

[code lang=”xml”]
&amp;lt;project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"&amp;gt;
&amp;lt;modelVersion&amp;gt;4.0.0&amp;lt;/modelVersion&amp;gt;
&amp;lt;groupId&amp;gt;net.javabeat&amp;lt;/groupId&amp;gt;
&amp;lt;artifactId&amp;gt;springboot-logging&amp;lt;/artifactId&amp;gt;
&amp;lt;version&amp;gt;0.1&amp;lt;/version&amp;gt;
&amp;lt;name&amp;gt;SpringBoot Logging&amp;lt;/name&amp;gt;
&amp;lt;properties&amp;gt;
&amp;lt;java.version&amp;gt;1.8&amp;lt;/java.version&amp;gt;
&amp;lt;start-class&amp;gt;net.javabeat.SpringBootLoggingDemo&amp;lt;/start-class&amp;gt;
&amp;lt;/properties&amp;gt;
&amp;lt;parent&amp;gt;
&amp;lt;groupId&amp;gt;org.springframework.boot&amp;lt;/groupId&amp;gt;
&amp;lt;artifactId&amp;gt;spring-boot-starter-parent&amp;lt;/artifactId&amp;gt;
&amp;lt;version&amp;gt;1.2.3.RELEASE&amp;lt;/version&amp;gt;
&amp;lt;/parent&amp;gt;
&amp;lt;dependencies&amp;gt;
&amp;lt;dependency&amp;gt;
&amp;lt;groupId&amp;gt;org.springframework.boot&amp;lt;/groupId&amp;gt;
&amp;lt;artifactId&amp;gt;spring-boot-starter&amp;lt;/artifactId&amp;gt;
&amp;lt;/dependency&amp;gt;
&amp;lt;/dependencies&amp;gt;

&amp;lt;build&amp;gt;
&amp;lt;plugins&amp;gt;
&amp;lt;plugin&amp;gt;
&amp;lt;groupId&amp;gt;org.springframework.boot&amp;lt;/groupId&amp;gt;
&amp;lt;artifactId&amp;gt;spring-boot-maven-plugin&amp;lt;/artifactId&amp;gt;
&amp;lt;/plugin&amp;gt;
&amp;lt;/plugins&amp;gt;
&amp;lt;/build&amp;gt;
&amp;lt;/project&amp;gt;
[/code]

The dependency spring-boot-starter includes the dependencies for logging spring-boot-starter-logging, so we need not add the logging dependency again. The spring-boot-starter-logging includes SLF4J and logback dependencies with appropriate SLF4J wrappers for other logging libraries.

Default Logging Support in Spring Boot

Spring Boot reference document says:

By default, If you use the ‘Starter POMs’, Logback will be used for logging. Appropriate Logback routing is also included to ensure that dependent libraries that use Java Util Logging, Commons Logging, Log4J or SLF4J will all work correctly.

Let us create SpringBootLoggingDemo class in net.javabeat package which will be the starting point for our application. By default the logging will be written to the console using a fixed logging format used by logback as shown below:

[code]
09:59:03.086 [net.javabeat.SpringBootLoggingDemo.main()] ERROR net.javabeat.SpringBootLoggingDemo – Message logged at ERROR level
[/code]

The above log contains of following parts:

1. Time with millisecond precision
2. Name of the thread in square brackets ([])
3. Log level
4. Logger name, generally class name truncated for brevity
5. Actual log message

The default log level configured by logback is DEBUG i.e any messages logged at ERROR, WARN, INFO and DEBUG get printed on the console. Let us create the SpringBootLoggingDemo class with a logger and log messages at ERROR, WARN, INFO and DEBUG level as shown below:

[code lang=”java”]
package net.javabeat;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class SpringBootLoggingDemo {

private static final Logger logger = LoggerFactory.getLogger(SpringBootLoggingDemo.class);

public static void main(String[] args) {
SpringApplication springApplication = new SpringApplication(new Object[]{SpringBootLoggingDemo.class});
springApplication.run(args);

logger.error("Message logged at ERROR level");
logger.warn("Message logged at WARN level");
logger.info("Message logged at INFO level");
logger.debug("Message logged at DEBUG level");

}
}
[/code]

Run the application using the command: mvn spring-boot:run to see the log messages printed on the console as shown:

[code lang=”shell”]
10:01:40.996 [net.javabeat.SpringBootLoggingDemo.main()] ERROR net.javabeat.SpringBootLoggingDemo – Message logged at ERROR level
10:01:40.996 [net.javabeat.SpringBootLoggingDemo.main()] WARN net.javabeat.SpringBootLoggingDemo – Message logged at WARN level
10:01:40.996 [net.javabeat.SpringBootLoggingDemo.main()] INFO net.javabeat.SpringBootLoggingDemo – Message logged at INFO level
10:01:40.996 [net.javabeat.SpringBootLoggingDemo.main()] DEBUG net.javabeat.SpringBootLoggingDemo – Message logged at DEBUG level
[/code]

Modifying the default configuration by providing logback.xml

Let us now modify the default logback configuration by providing a logback.xml configuration file as shown below:

[code lang=”xml”]
&amp;lt;?xml version="1.0" encoding="UTF-8"?&amp;gt;
&amp;lt;configuration&amp;gt;
&amp;lt;appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"&amp;gt;
&amp;lt;!– Log message format –&amp;gt;
&amp;lt;encoder&amp;gt;
&amp;lt;pattern&amp;gt;%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} – %msg%n
&amp;lt;/pattern&amp;gt;
&amp;lt;/encoder&amp;gt;
&amp;lt;/appender&amp;gt;

&amp;lt;!– Setting the root level of logging to INFO –&amp;gt;
&amp;lt;root level="info"&amp;gt;
&amp;lt;appender-ref ref="STDOUT" /&amp;gt;
&amp;lt;/root&amp;gt;
&amp;lt;/configuration&amp;gt;
[/code]

The above configuration does the following:

• Set up a appender STDOUT using ConsoleAppender which prints to the console
• Provide a pattern to the appender to build the log message
• Set up a root logger which logs any message above INFO level using the STDOUT appender

We have to place this logback.xml in the classpath of the application for Spring Boot to pick the configuration. I have placed this in src/main/resources as shown below:
Let us run the application again using mvn spring-boot:run and see that only ERROR, WARN, INFO are logged and the one DEBUG is not logged as shown below:

[code lang=”shell”]
14:04:23.805 [net.javabeat.SpringBootLoggingDemo.main()] ERROR net.javabeat.SpringBootLoggingDemo – Message logged at ERROR level
14:04:23.808 [net.javabeat.SpringBootLoggingDemo.main()] WARN net.javabeat.SpringBootLoggingDemo – Message logged at WARN level
14:04:23.809 [net.javabeat.SpringBootLoggingDemo.main()] INFO net.javabeat.SpringBootLoggingDemo – Message logged at INFO level
[/code]

This was a simple logback.xml configuration. Let us see how we can configure it to set different log levels for different java packages in the application. For that let us first create two classes: TestModel.java in net.javabeat.model and TestService.java in net.javabeat.service as as shown below:

TestModel.java

[code lang=”java”]
package net.javabeat.model;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class TestModel {
private static final Logger logger = LoggerFactory.getLogger(TestModel.class);

public TestModel(){
logger.debug("Log message at DEBUG level from TestModel constructor");
logger.info("Log message at INFO level from TestModel constructor");
}
}
[/code]

TestService.java

[code lang=”java”]
package net.javabeat.service;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class TestService {

private Logger logger = LoggerFactory.getLogger(TestService.class);

public void service(){
logger.info("Message at INFO level from TestService.service()");
logger.warn("Message at WARN level from TestService.service()");
}
}
[/code]

The project structure with these new files looks like below:

We are going to set the log level to WARN for net.javabeat.service package and to INFO for net.javabeat.model package as show below:

[code lang=”xml” highlight=”7,14″]
&amp;lt;?xml version="1.0" encoding="UTF-8"?&amp;gt;
&amp;lt;configuration&amp;gt;
&amp;lt;appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"&amp;gt;
&amp;lt;!– Log message format –&amp;gt;
&amp;lt;encoder&amp;gt;
&amp;lt;pattern&amp;gt;%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} – %msg%n&amp;lt;/pattern&amp;gt;
&amp;lt;/encoder&amp;gt;
&amp;lt;/appender&amp;gt;

&amp;lt;!– Setting the logging level to WARN for code in net.javabeat.service –&amp;gt;
&amp;lt;logger name="net.javabeat.service" level="WARN" /&amp;gt;

&amp;lt;!– Setting the logging level to INFO for code in net.javabeat.model –&amp;gt;
&amp;lt;logger name="net.javabeat.model" level="INFO" /&amp;gt;

&amp;lt;!– Setting the root level of logging to INFO –&amp;gt;
&amp;lt;root level="info"&amp;gt;
&amp;lt;appender-ref ref="STDOUT" /&amp;gt;
&amp;lt;/root&amp;gt;
&amp;lt;/configuration&amp;gt;
[/code]

We would have to update the SpringBootLoggingDemo class and add the below lines just before creating a new instance of SpringApplication:

[code language=””]
TestModel model = new TestModel();
TestService service = new TestService();
service.service();
[/code]

Now, running the application give us the below output:

[code lang=”shell”]
17:36:07.616 [net.javabeat.SpringBootLoggingDemo.main()] ERROR net.javabeat.SpringBootLoggingDemo – Message logged at ERROR level
17:36:07.632 [net.javabeat.SpringBootLoggingDemo.main()] WARN net.javabeat.SpringBootLoggingDemo – Message logged at WARN level
17:36:07.632 [net.javabeat.SpringBootLoggingDemo.main()] INFO net.javabeat.SpringBootLoggingDemo – Message logged at INFO level
17:36:07.632 [net.javabeat.SpringBootLoggingDemo.main()] INFO net.javabeat.model.TestModel – Log message at INFO level from TestModel constructor
17:36:07.632 [net.javabeat.SpringBootLoggingDemo.main()] WARN net.javabeat.service.TestService – Message at WARN level from TestService.service()
[/code]

You can observe that for TestModel the message at DEBUG level was not logged and for TestService the message at INFO level was not logged.

Sending the log messages to a file

In this tutorial I am using the logback.xml as the logging configuration. Spring boot by default uses the logback as the default logging implementation if you are not specifying any other implementations. If you want to write the log files to an file but you don’t want to use the logback.xml file for the configurations, you can use the spring boot properties logging.path or logging.file to specify the location of the log files.

Spring boot will look for the above two properties, if those are are not specified then the log messages are sent to the console appender. Otherwise the log messages will be sent to file specified by those properties.

Now let’s look at how to use the logback for printing the log message sin the files. Till now we saw the log messages being printed on console, let us now see how the same can be written to a file. We need to update logback.xml configuration to add a new appender to write to file and then use that appender in the loggers defined in the configuration file as shown below:

[code lang=”xml” highlight=”10-16,18,21,26″]
&amp;lt;?xml version="1.0" encoding="UTF-8"?&amp;gt;
&amp;lt;configuration&amp;gt;
&amp;lt;appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"&amp;gt;
&amp;lt;!– Log message format –&amp;gt;
&amp;lt;encoder&amp;gt;
&amp;lt;pattern&amp;gt;%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} – %msg%n&amp;lt;/pattern&amp;gt;
&amp;lt;/encoder&amp;gt;
&amp;lt;/appender&amp;gt;
&amp;lt;!– Ned appender to write to file –&amp;gt;
&amp;lt;appender name="FILE" class="ch.qos.logback.core.FileAppender"&amp;gt;
&amp;lt;!– Name of the file where the log messages are written –&amp;gt;
&amp;lt;file&amp;gt;myApp.log&amp;lt;/file&amp;gt;
&amp;lt;encoder&amp;gt;
&amp;lt;pattern&amp;gt;%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} – %msg%n&amp;lt;/pattern&amp;gt;
&amp;lt;/encoder&amp;gt;
&amp;lt;/appender&amp;gt;
&amp;lt;logger name="net.javabeat.service" level="WARN"&amp;gt;
&amp;lt;appender-ref ref="FILE" /&amp;gt;
&amp;lt;/logger&amp;gt;
&amp;lt;logger name="net.javabeat.model" level="INFO"&amp;gt;
&amp;lt;appender-ref ref="FILE" /&amp;gt;
&amp;lt;/logger&amp;gt;

&amp;lt;!– Setting the root level of logging to INFO –&amp;gt;
&amp;lt;root level="info"&amp;gt;
&amp;lt;appender-ref ref="FILE" /&amp;gt;
&amp;lt;/root&amp;gt;
&amp;lt;/configuration&amp;gt;
[/code]

Now running the application will redirect all the log messages to the file myApp.log present in the current directory.

Making use of default logback configuration base.xml

Till now we haven’t made use of Spring Boot features or the defaults it provides. In this section we are going to show you how we can make use of the logback configuration base.xml. Base.xml sets up the following things:

• Wiring the spring properties- logging.file, logging.path with the logback configuration
• Setting up console and file appenders
• Setting log levels for some packages

Let us update the logback.xml configuration file with the below configuration:

[code lang=”xml”]
&amp;lt;?xml version="1.0" encoding="UTF-8"?&amp;gt;
&amp;lt;configuration&amp;gt;
&amp;lt;include resource="org/springframework/boot/logging/logback/base.xml"/&amp;gt;
&amp;lt;logger name="net.javabeat.service" level="WARN"&amp;gt;&amp;lt;/logger&amp;gt;
&amp;lt;logger name="net.javabeat.model" level="INFO"&amp;gt;&amp;lt;/logger&amp;gt;
&amp;lt;/configuration&amp;gt;
[/code]

And add application.properties file with a property logging.file having the name of the file as shown: logging.file=demo_logging.log. The logging will now be written both to the console and to the file. Let us verify this by running the application using mvn spring-boot:run to get the below log messages printed on console and in the file demo_logging.log:

[code lang=”shell”]
…
2015-08-18 19:35:09.725 ERROR 7316 — [net.javabeat.SpringBootLoggingDemo.main()] net.javabeat.SpringBootLoggingDemo : Message logged at ERROR level
2015-08-18 19:35:09.725 WARN 7316 — [net.javabeat.SpringBootLoggingDemo.main()] net.javabeat.SpringBootLoggingDemo : Message logged at WARN level
2015-08-18 19:35:09.725 INFO 7316 — [net.javabeat.SpringBootLoggingDemo.main()] net.javabeat.SpringBootLoggingDemo : Message logged at INFO level
2015-08-18 19:35:09.726 INFO 7316 — [net.javabeat.SpringBootLoggingDemo.main()] net.javabeat.model.TestModel : Log message at INFO level from TestModel constructor
2015-08-18 19:35:09.727 WARN 7316 — [net.javabeat.SpringBootLoggingDemo.main()] net.javabeat.service.TestService : Message at WARN level from TestService.service()
…

C:\Users\Mohamed\workspace\springboot-logging&amp;gt;more demo_logging.log
…
2015-08-18 19:35:09.725 ERROR 7316 — [net.javabeat.SpringBootLoggingDemo.main()] net.javabeat.SpringBootLoggingDemo : Message logged at ERROR level
2015-08-18 19:35:09.725 WARN 7316 — [net.javabeat.SpringBootLoggingDemo.main()] net.javabeat.SpringBootLoggingDemo : Message logged at WARN level
2015-08-18 19:35:09.725 INFO 7316 — [net.javabeat.SpringBootLoggingDemo.main()] net.javabeat.SpringBootLoggingDemo : Message logged at INFO level
2015-08-18 19:35:09.726 INFO 7316 — [net.javabeat.SpringBootLoggingDemo.main()] net.javabeat.model.TestModel : Log message at INFO level from TestModel constructor
2015-08-18 19:35:09.727 WARN 7316 — [net.javabeat.SpringBootLoggingDemo.main()] net.javabeat.service.TestService : Message at WARN level from TestService.service()
[/code]

You can see that with a minimal logback.xml we have achieved a lot more, thanks to the defaults provided by Springboot. The code for this article can be found here.

Conclusion

I hope this tutorial have provided enough insight on how to use the logging mechanism in Spring Boot application. Also I have written about the default logging support in the Spring Boot applications and how to override them by modifying the logback.xml file. If you have any questions in logging configuration in spring boot, please write it in the comments section.

This tutorials explains you the different ways how you can do external configurations for Spring Boot applications. When you work with the real time environments, External Configurations for Spring Boot would become important for the flexibility. If you have any questions, please write it in the comments section.

Spring Boot : External Configurations for #SpringBoot http://t.co/tEFQ71UP3w pic.twitter.com/u8rwUB7iJ5

— JavaBeat (@javabeat) August 14, 2015

Applications have to store configuration of its database i.e the hostname of the db, the name of the database, user of the db, then there is information like hostname of any entities the application is dependent on, some spring related configuration overrides and so on. The spring related configurations can be found here.

There are multiple sources from where the configuration can be read from and the order in which the configuration properties are overridden is determined by Spring Boot. The order as described here is listed below:

• Command line arguments
• JNDI attributes from java:comp/env
• Java System properties (System.getProperties())
• OS environment variables
• A RandomValuePropertySource that only has properties in random.*
• Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants)
• Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants)
• Application properties outside of your packaged jar (application.properties and YAML variants)
• Application properties packaged inside your jar (application.properties and YAML variants)
• @PropertySource annotations on your @Configuration classes
• Default properties (specified using SpringApplication.setDefaultProperties)

In this post I am going to show you how to define properties using the following approaches:

• Command line arguments
• Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants)
• Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants)
• Application properties outside of your packaged jar (application.properties and YAML variants)
• Application properties packaged inside your jar (application.properties and YAML variants)
• Default properties (specified using SpringApplication.setDefaultProperties)

Lets create a basic SpringBoot application as explained in this article. In short, you would have to create a maven project and update the pom.xml as shown below:

[code lang=”xml” highlight=”11″]
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.intbittech</groupId>
<version>1.0</version>
<name>DocAppAPI</name>
<description>RESTful API for DocApp</description>
<artifactId>DocAppAPI</artifactId>
<properties>
<java.version>1.8</java.version>
<start-class>net.javabeat.ExternalConfigApplication</start-class>
</properties>
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.2.3.RELEASE</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
[/code]

In the above highlighted code we haven’t yet created the class ExternalConfigApplication. It would be the starting point for our SpringBoot application. The ExternalConfigApplication class definition is given below:

[code lang=”java”]
package net.javabeat;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class ExternalConfigApplication {

public static void main(String[] args) throws Exception {
SpringApplication.run(new Object[] { ExternalConfigApplication.class }, args);
}

}
[/code]

I will also create a component class ExternalConfigComponent annotated with @Component whose definition is shown below:

[code lang=”java”]
package net.javabeat;

import javax.annotation.PostConstruct;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Component;

@Component
public class ExternalConfigComponent {
private static Logger logger = LoggerFactory.getLogger(ExternalConfigComponent.class);

//No properties configured yet.

@PostConstruct
public void postConstruct(){
//This is where we are going to print the values of the properties
}
}
[/code]

Let us compile and run the above application as shown below:

[code lang=”shell”]
C:\Users\Mohamed\workspace\springboot-external-config>mvn clean package
…
…
[INFO] ————————————————————————
[INFO] BUILD SUCCESS
[INFO] ————————————————————————
[INFO] Total time: 3.547 s
[INFO] Finished at: 2015-08-09T21:55:30+05:30
[INFO] Final Memory: 22M/218M
[INFO] ————————————————————————

C:\Users\Mohamed\workspace\springboot-external-config>java -jar target\SpringBootExternalConfig-1.0.jar
…
2015-08-09 21:56:29.592 INFO 10444 — [ main] net.javabeat.ExternalConfigApplication : Started ExternalConfigApplication in 1.195 seconds (JVM running for 1.675)
…
[/code]

You will notice that the application starts and then terminates successfully. As this is just any other Java based command line application, it executes the application and then exits unlike Web applications.

Another way to compile and run the application in one go is to use the spring-boot maven plugin as shown below:

[code lang=”shell”]
C:\Users\Mohamed\workspace\springboot-external-config>mvn spring-boot:run
[/code]

Through out the post I am going to use the above spring-boot maven plugin to run the application.

Now let us start exploring the external configurations for Spring Boot applications.

External Configurations for Spring Boot

Default properties (specified using SpringApplication.setDefaultProperties)

SpringApplication has an API setDefaultProperties which accepts a Map or a Properties object. I am enhancing the ExternalConfigApplication class to set the values for two properties namely: property.one and property.two as shown below:

[code lang=”java” highlight=”21-27″]
package net.javabeat;

import java.util.HashMap;
import java.util.Map;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class ExternalConfigApplication {

private static final Logger logger = LoggerFactory.getLogger(ExternalConfigApplication.class);

@Autowired
private ExternalConfigComponent externalConfigComponent;

public static void main(String[] args) throws Exception {
SpringApplication springApplication = new SpringApplication(new Object[] { ExternalConfigApplication.class });

Map<String, Object> defaultProperties = new HashMap<String, Object>();
defaultProperties.put("property.one", "Value One");
defaultProperties.put("property.two", "Value Two");

springApplication.setDefaultProperties(defaultProperties);

springApplication.run(args);

}

}
[/code]

Let us access the two properties defined above by binding them to two fields in the ExternalConfigComponent using the @Value annotation as shown below:

[code lang=”java”]
package net.javabeat;

import javax.annotation.PostConstruct;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Component;

@Component
public class ExternalConfigComponent {
private static Logger logger = LoggerFactory.getLogger(ExternalConfigComponent.class);

@Value("${property.one}")
public String propertyOne;

@Value("${property.two}")
public String propertyTwo;

@PostConstruct
public void postConstruct(){
logger.info("Property One: " + propertyOne);
logger.info("Property Two: " + propertyTwo);
}

}
[/code]

Lets launch the above application using the spring-boot maven plugin as shown below:

[code lang=”shell” highlight=”3,4″]
$ mvn spring-boot:run
…
2015-08-10 01:46:59.530 INFO 4964 — [lication.main()] net.javabeat.ExternalConfigComponent : Property One: Value One
2015-08-10 01:46:59.530 INFO 4964 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Two: Value Two
…
[/code]

Among the lot of text printed on the console you can find the above two lines with the value of the property.

Application properties packaged inside your jar

Another approach is to create a file by name application.properties and package it with your jar. This file contains the key, value pairs for the properties. One can name these property files with any name, but the name has to be provided to the spring configuration property so that it can read that file. By default spring searches for application.properties file. Let us create application.properties in the folder src/main/resources as shown in the image below:

And the contents of the application.properties is as shown below:

[code]
property.two=Value Two Overridden
property.three=Value Three
[/code]

It contains two properties namely: property.two and property.three. You might wonder about the name property.two being repeated. Yes, it is repeated and the purpose of this repetition is to show the overriding of the properties. The order of precedence of property sources has already been listed in the beginning and the Default Properties comes at the last, preceded by the application.properties file packaged in the jar. So lets see this overriding in action. Before that lets update the ExternalConfigComponent class with the new property as shown below:

[code lang=”java” highlight=”20,21,27″]
package net.javabeat;

import javax.annotation.PostConstruct;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Component;

@Component
public class ExternalConfigComponent {
private static Logger logger = LoggerFactory.getLogger(ExternalConfigComponent.class);

@Value("${property.one}")
private String propertyOne;

@Value("${property.two}")
private String propertyTwo;

@Value("${property.three}")
private String propertyThree;

@PostConstruct
public void postConstruct(){
logger.info("Property One: " + propertyOne);
logger.info("Property Two: " + propertyTwo);
logger.info("Property Three: " + propertyThree);
}

}
[/code]

Lets launch the application and view its output:

[code lang=”shell” highlight=”4,5″]
$ mvn spring-boot:run
…
2015-08-10 02:03:34.572 INFO 920 — [lication.main()] net.javabeat.ExternalConfigComponent : Property One: Value One
2015-08-10 02:03:34.572 INFO 920 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Two: Value Two Overridden
2015-08-10 02:03:34.573 INFO 920 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Three: Value Three
…
[/code]

You can observe above that the value of Property Two has been overridden by the value specified in the application.properties file.

Application properties outside of your packaged jar

Above we saw application.properties packaged inside the jar, now let us see how application.properties file can be placed in the /config sub directory of the current directory and let Springboot load the properties defined in that file. The content of this application.properties files is given below:

[code]
property.three=Value Three Overridden
property.four=Value Four
[/code]

As usual there are two properties property.three and property.four. Let us see the updated code for ExternalConfigComponent below:

[code lang=”java” highlight=”30, 31″]
//Add this below along with the other property declarations
@Value("${property.four}")
private String propertyFour;

//Append the below to the postConstruct() method
logger.info("Property Four: " + propertyFour);
[/code]

Running the application gives us the below output:

[code lang=”shell” highlight=”4″]
….
2015-08-14 17:06:13.469 INFO 12624 — [lication.main()] net.javabeat.ExternalConfigComponent : Property One: Value One
2015-08-14 17:06:13.470 INFO 12624 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Two: Value Two Overridden
2015-08-14 17:06:13.471 INFO 12624 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Three: Value Three Overridden
2015-08-14 17:06:13.472 INFO 12624 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Four: Value Four
…
[/code]

You will notice in the highlighted lines above that the property defined in the application.properties file defined inside the Jar has been overridden by the application.properties defined outside the jar in the /config sub directory.

Profile-specific application properties packaged inside your jar

We can have multiple values for a property depending on the environment the application is running in i.e dev environment or production environment. To support this feature Springboot has concept called profiles. One can create a profile by name local for local environment, then dev for development environment and so on. So the names of the property files will now be application-local.properties and application-dev.properties respectively.

The profile can be selected by setting the profile name in the Spring property spring.profiles.active. We can set this value using any one of the approaches defined here, and we would use the approach to set the value via command line. But before we show that let us see the contents of the application-local.properties:

[code]
property.four=Value Four Overridden
property.five=Value Five
[/code]

Let us update the ExternalConfigComponent to accomodate the new property property.five with the below code:

[code lang=”java”]
//Add this below along with the other property declarations
@Value("${property.five}")
private String propertyFive;

//Append the below to the postConstruct() method
logger.info("Property Five: " + propertyFive);
[/code]

Let us run the application by using the command: mvn spring-boot:run -Dspring.profiles.active=local. After the application is run successfully you will see the below output:

[code lang=”shell” highlight=”5,6″]
…
2015-08-14 17:37:29.348 INFO 8760 — [lication.main()] net.javabeat.ExternalConfigComponent : Property One: Value One
2015-08-14 17:37:29.348 INFO 8760 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Two: Value Two Overridden
2015-08-14 17:37:29.348 INFO 8760 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Three: Value Three Overridden
2015-08-14 17:37:29.348 INFO 8760 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Four: Value Four Overridden
2015-08-14 17:37:29.348 INFO 8760 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Five: Value Five
…
[/code]

You can notice that the property property.four from the /config/application.properties has been overridden by application-local.properties and also the new property property.five provided by the new properties files.

Profile-specific application properties outside of your packaged jar

Just as we saw with application.properties placed in the jar and outside the jar in a sub directory, we can do the same with profile specific application properties. Let us create application-local.properties with the below data and store it in the /config sub directory created earlier:

[code]
property.five=Value Five Overridden
property.six=Value Six
[/code]

And the below are the updates to the ExternalConfigComponent:

[code lang=”java”]
//Add this below along with the other property declarations
@Value("${property.six}")
private String propertySix;

//Append the below to the postConstruct() method
logger.info("Property Six: " + propertySix);
[/code]

Let us run the application by using the command: mvn spring-boot:run -Dspring.profiles.active=local. After the application is run successfully you will see the below output:

[code lang=”shell”]
…
015-08-14 17:51:59.469 INFO 11564 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Five: Value Five Overridden
2015-08-14 17:51:59.469 INFO 11564 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Six: Value Six
..
[/code]

You can notice the above two lines printed among other lines in the output after executing the program. So the application-local.properties file in the /config sub directory has overridden the property.five defined in the application-local.properties packaged in the jar.

Command line arguments

The value for these properties are passed via command line while launching the application. I am going to configure two properties by name: property.six and property.seven and bind them to our ExternalConfigComponent class as shown below:

[code lang=”java”]
//Add this below along with the other property declarations
@Value("${property.seven}")
private String propertySeven;

//Append the below to the postConstruct() method
logger.info("Property Seven: " + propertySeven);
[/code]

Lets try to launch the application by passing the values for the above two configuration properties as shown below:

[code lang=”shell” highlight=”3,4″]
C:\Users\Mohamed\workspace\springboot-external-config>mvn spring-boot:run -Dspring.profiles.active=local -Dproperty.six="Value Six Overridden" -Dproperty.seven="Value Seven"
…
2015-08-14 19:24:23.430 INFO 5584 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Six: Value Six Overridden
2015-08-14 19:24:23.430 INFO 5584 — [lication.main()] net.javabeat.ExternalConfigComponent : Property Seven: Value Seven
…
[/code]

You can see the values of the configuration properties (highlighted above) printed on the console among other outputs and also see that the value for property.six has been overridden by the value passed as a command line argument.

With this we come to an end of the article. We have shown you different ways we can setup properties in Spring Boot and also how the order/precedence of the sources override the values defined in different property sources. If you have any questions on External Configurations for Spring Boot, please write it in the comments section.

The complete code can be accessed from Github here. If you want to run the complete code then you have to make use of the command: mvn spring-boot:run -Dspring.profiles.active=local -Dproperty.six="Value Six Overridden" -Dproperty.seven="Value Seven".