Java Ninja Chronicles By Norris Shelton

Things I learned in the pursuit of code

Tomcat access logs are not enabled in Spring Boot by default. The access logs can be a very useful troubleshooting tool. The logs can be enabled by adding a property to the in the src/main/resources directory.

# Enable access log.

This will enable Tomcat Access Logging. The logs will go to the current temporary directory where the existing Tomcat work directory is located. The logs will appear under a directory named logs in a file that follows the normal Tomcat Access logs, such as access_log.2019-02-04.log.

It is a good idea to specify the directory that you want to contain the Tomcat logs, etc instead of relying on them being sent to a temporary directory. You can specify the Tomcat Basedir by adding the following to the

# Tomcat base directory, which will be at the same level as the 
# Spring Boot jar. If not specified, a temporary directory
# is used.

The directory with the specified name will be created at the same directory level as the .jar that contains the Spring Boot application. If you are running the application as part of your IDE, then the specified directory will appear in the root of your source code.

An alternative way to specify the properties is to specify them as JVM parameters. An example of both of these would be

-Dserver.tomcat.basedir=tomcat -Dserver.tomcat.accesslog.enabled=true

Tomcat Access Logs can be easily enabled in a Spring Boot application by setting the appropriate property. This allows easy troubleshooting and if you set the Tomcat basedir, you can also access Tomcat’s work directory.

Additional information about configuring Spring Boot Tomcat can be found at

February 5th, 2019

Posted In: Javaninja

Tags: , , , ,

Leave a Comment

Spring Boot

Spring Boot is changing the world of Java development with Spring. It is taking away much of the pain that was involved with configuring applications. This is great when you are trying to create what they do by default. They create executable jars by default. What do you have to do if you need to create a WAR file to run on a Tomcat by someone else.

POM file

Let’s start with our project’s pom.xml file. Here we need to define the standard Spring Boot parent starter and also include include the Spring Boot Web starter. The Spring Boot Web starter also includes the Spring Boot Tomcat starter. In our case, we do not want it packaged inside our war because our war file will be deployed on a Tomcat server directly. We don’t have to roll our own. To change this behavior, we include the Spring Boot tomcat starter explicitly and set it’s scope to provided. We also must specify the packaging of our project to be a war.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns=""






Java Config

Normally the Java Configuration contains a main method because that is how the program will be launched. In this case, we do not need a main method and instead we need to provide a configure method to go along with the SpringBootServletInitializer that we extend.

package com.javaninja.springboot.web;

import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;

public class WebApplication extends SpringBootServletInitializer {

    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        return application.sources(WebApplication.class);

Example Controller

That is all of the configuration that we need to make this work as a normal Spring MVC controller. To test our functionality, we need a very simple controller, such as the following,.

package com.javaninja.springboot.web;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

public class ExampleController {

    private Logger log = LoggerFactory.getLogger(getClass());

    public Boolean exampleBoolean() {"Eureka!");
        return true;

Test the controller

Let’s create a very simple test using the Spring Boot Test starter. This brings in Junit and MockMvc among other useful APIs.

package com.javaninja.springboot.web;

import org.junit.Test;
import org.junit.runner.RunWith;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.http.MediaType;
import org.springframework.test.context.junit4.SpringRunner;
import org.springframework.test.web.servlet.MockMvc;

import static;
import static org.springframework.test.web.servlet.request.MockMvcRequestBuilders.get;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content;
import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status;

 * @author norris.shelton
public class TestExampleController {

    private MockMvc mvc;

    public void testExampleBoolean() {
        try {
        } catch (Exception e) {

The test run perfectly and produces the following logging and a nice pretty green bar.

2017-07-10 18:36:06.218  INFO 7499 --- [           main] c.j.springboot.web.ExampleController     : Eureka!

July 11th, 2017

Posted In: Maven, MockMVC, Spring, Spring Boot, Spring MVC, Test Driven Development, Unit Tests

Tags: , ,

Leave a Comment

WP to LinkedIn Auto Publish Powered By :