Edit: see also the follow up article on how to Test log4j with JUnit if you’re interested in specifically testing log output.
Just occasionally, it can be useful to verify output to System.out in a unit test. For example, if you’re testing application logging or if you’re using log output to sense some other behaviour. It can be tricky to properly mock behaviour of System.out but fortunately, it is possible to test System.out with JUnit.
Spring Boot Actuator provides assistance for application monitoring. Out of the box it provides information on application health, configuration and logging. It’s trivial to enable: simply add the spring-boot-starter-actuator dependency to a Spring Boot project in Maven or Gradle and it just works! The monitoring information is provided as JSON from HTTP endpoints or via JMX.
The Spring Boot Actuator trace endpoint is particularly handy. By default it shows the last 100 HTTP requests made to the application. This article walks through an Actuator demo and shows some of the configuration options to get the best from this feature.
Like a many things in Tomcat, there are a number of ways to enable remote debugging. Here’s the easiest way I’ve found to enable remote debugging in a Docker container running Tomcat.
The wonderful docker-maven-plugin from Spotify is a great way to build Docker images from Maven. If you bind it to Maven phases, it can be used to make a one-step build of a project artifact and its Docker image. For example, if you bind the Docker Maven plugin’s build goal to the Maven package phase, it will create your Docker image when you run a standard
mvn clean install
command. That’s neat, but the drawback is that the build will fail entirely if Docker is not available on the build machine. This somewhat goes against the Maven ideal of portable builds – we don’t want a build that works on my machine but not yours.
We can workaround this problem by making the Docker build optional and enabling only if Docker is available.
The documentation provided by Spring on deploying a Spring Boot application as a Windows Service is a little sparse. Indeed, here it is in full:
Spring Boot application can be started as Windows service using
winsw.A sample maintained separately to the core of Spring Boot describes step-by-step how you can create a Windows service for your Spring Boot application.
— From Spring Boot Reference Guide (version 1.4.3), section 56.2: Microsoft Windows Services
As the official reference guide is lacking detail, here is a step by step guide to building and deploying a Spring Boot application as a Windows Service.
One of the standard problems with Microservices Architecture is the issue of service discovery. Once we’ve decomposed our application into more than a handful of distinct microservices, it becomes difficult for every service to know the address of every other service it depends on. Configuring dependencies from inside a microservice is impractical – it distributes configuration among all the microservices. It also violates the DRY principle – multiple microservice instances will need access to the same configuration settings. What’s more, it goes against the Dependency Injection design that’s supposed to be one of the benefits of the Microservices Architecture.
The standard solution is to delegate location of microservices to a new microservice. In keeping with the Single Responsibility Principle, this ‘discovery’ microservice is responsible for tracking the locations of all the other microservices and nothing else.
Netflix’s Eureka is an implementation of a discovery server and integration is provided by Spring Boot. Using Spring Boot, we can build a Eureka discovery server and have our microservices register with it.
Spring Boot 1.4.0 is now available. Among the enhancements are new mechanisms to build and test RestTemplates used to make calls to RESTful web services.
A standard use case for Docker is to build a container to run a pre-built application so that the containerized app can be run on any Docker enabled host. The application and the container are sometimes developed and built separately. First the application is built, then a container is defined and built to include the application. However, it can be better to promote the Docker container to a first-class build artifact. That is, the build process always builds the deployed component and its container at the same time. This saves a manual build step and also ensures that the Docker container is always up to date with the latest application build. It allows us to easily develop and test against the Dockerized application directly – every build results in a new deployable container.
There are a number of ways to do this. This article looks at hooking the Docker tasks into the Maven build process.
CRUD REST services are the backbone of a microservice architecture. If we want to use microservices rather than monolithic applications, it’s essential that we can create a basic service with a minimum of effort. Spring Boot can be used to quickly create and deploy a new web service. Spring Data REST can be used to build out the REST interface based on a database entity model. Using both together allows us to create a running RESTful web service with zero custom Java code and no tricky XML.
This article describes how to build a RESTful web service as an executable JAR that provides CRUD operations against a single MySQL database table.
This demo can be downloaded from GitHub in the Spanners Demo Application version 4.0 (spanners-api module). You can run the working example as a docker-compose stack, along with the associated MySQL database and the Spring MVC web app that consumes the service (see the previous post on docker-compose for details on how to run this).