Jenkins Multibranch Pipeline

jenkins-logoI recently upgraded Jenkins ( to the 2.0 version and had to setup all the jobs again. It is quite a manual process and I wonder if this can be automated in some way.

Gradle plugin

There exists a Gradle plugin (a plugin to use in a Gradle build script) to automate setting up a Jenkins server, see This solution automates the one-time process of setting up jobs. I find this approach interesting, although a bit too much at this point.

Multibranch Pipeline jobs

In the Jenkins 2.0 version, I noticed Multibranch Pipeline jobs – these jobs get most of their configuration from a script that you put in the source repository. This is a great solution, since you can version the configuration and don’t have the manually enter at the Jenkins user interface. Another great feature is that a multibranch pipeline scans your Git repository for branches and builds all of those branches automatically.


The way you configure a Multibranch Pipeline is by configuring the repository and how the build is triggered. The easiest way is to trigger periodically. That is all the configuration that you enter on the Jenkins user interface.


After this configuration, Jenkins will look at all your branches in the repository and look for a file in the root with the name “Jenkinsfile”. This file should contain a Groovy script that performs the build.

node {
 checkout scm
 sh "./gradlew clean build"

This script will checkout the branch from the repository and execute “./gradlew clean build”. After you added this file to your repository, you can manually trigger Jenkins with Build Indexing/Run Now. You will will see a list with all the branches that have a Jenkinsfile.




This is great if you want to make sure that the code that is committed the repository actually compiles.

To take a step further, you probably want to run your unit tests and show the results. You can just use the “test” task:

node {
 checkout scm
 sh "./gradlew clean test"

This will run the build and test in one step. To make a clearer overview of the whole process, you can defines stages and impose timeouts:

node {
 stage 'checkout'
 checkout scm

stage 'build'
 timeout(time: 15, unit: 'MINUTES') {
 sh "./gradlew clean build"

stage 'test'
 timeout(time: 15, unit: 'MINUTES') {
 sh "./gradlew test"

This will produce a nice report of all the stages.


Now you can quickly see how long each stage took and if it is successful.

It would also be nice to show the results of the tests, and I will explore that in another post.

Creating a minimal Docker image with Glassfish

docker-logoI have been using Docker to run Glassfish in a container and I noticed some news about using Alpine Linux.Apparently, you create much smaller containers with Alpine Linux. This article from Atlassian ( mentioned a minimal base image with OpenJDK.

Since I prefer to use the Oracle JDK with Glassfish 4.1, I ran a few tests myself to compare a phusion baseimage with Alpine Linux.

My Phusion based container produced an image 1130 MB large, while the Alpine Linux based image was only 392 MB. To produce a working application, I used the Primefaces showcase WAR.

I am surprised about the size differences, see the resulting images:

Phusion baseimage + Java 8 + Glassfish 4.1

phusion/baseimage         305 MB
ubuntu-oracle-jdk8        892 MB
koert/glassfish-4.1       1130 MB
koert/glassfish-showcase  1156 MB

Alpine Linux + Java 8 + Glassfish 4.1

frolvlad/alpine-oraclejdk8       170.8 MB
koert/alpine-glassfish-4.1       391.8 MB
koert/alpine-glassfish-showcase  417.8 MB

My examples at Github


Functional style programming with Optional in Java 8

With the Java 8, we have a more functional style programming available and the Optional type. This type is like Option in Scala and should replace the commonly used pattern of returning null if something is not found or available.

See the below example of a repository – authenticateUser2 returns a null if it cannot authenticate the user.

Using Optional, authenticateUser returns Optional.empty is it cannot authenticate the user, otherwise it will return an Optional that wraps the AuthenticationToken with Optional.of.

Using the classical null-checking pattern, LoginService2 uses an if-then-else structure:

Using a functional style of checking for an empty result, LoginService uses the map and orElse methods:

This new style replaces 8 lines of code with 3 lines. You may wonder – what is the big deal – 5 lines of code?

At first glance, this map orElse pattern looks a little puzzling. After seeing this a few times, this new functional style describes the intention of the code more clearly than the if-then-else structure. The intention is that it returns a token, or else a not-acceptable status code.

The purpose of code is, next to implementing a solution, to communicate to the maintainer what you meant to do. We software developers sometimes spend too much time trying to understand what the code does, it would be great if we can see in one glance the intention – this will prevent many bugs and misunderstandings, and improve the quality of our work.


Restful service with JAX RS and CDI on Glassfish

I was working on a RESTful service with JAX RS on Glassfish and pieced together a working implementation with CDI dependency injection.


This REST service is pretty simple, when you access /test/hello?name=John with a GET, you will get “Hello world John” back. Note the @ManagedBean annotation – this will make CDI dependency injection working in a JAX RS instantiated service.

The HelloRepository is injected with CDI:

You can package this as a WAR file and deploy it on a Glassfish server. To make this work, you need a minimal web.xml in WEB-INF:

To enable CDI, you need an empty beans.xml in WEB-INF:

And to make JAX RS working correctly and set the root path, you need this class:

To set the context root, you could also add a glassfish-web.xml in WEB-INF – this is of course Glassfish specific.

After figuring this out, it is easy to configure and doesn’t need any complicated XML. I got the above configuration working on Glassfish 3 and 4.

Web application development with Docker and Glassfish

Although Docker is often used to deploy/run applications in a defined environment, you can also use Docker in your development environment. To make this productive, you need an easy way to deploy and debug your web application. In the Glassfish image (see I can add deploy a web application and hook into the file system.

Glassfish provides an autodeploy directory – just copy a war or ear file to this directory and Glassfish will deploy this automatically. You can mount this directory to your host with the -v option:

docker run ... -v ~/tmp/glassfish/deploy:/opt/glassfish4/glassfish/domains/domain1/autodeploy ...

To view the logs directory you can add this:

docker run ... -v ~/tmp/glassfish/logs:/opt/glassfish4/glassfish/domains/domain1/logs ...

I cloned a copy of the Spring petclinic application ( to setup my development environment. Curiously, I needed to add “implements Serializable” to BaseEntity, to make it work on Glassfish 4.1. Normally, the petclinic application creates its own datasource, not a JEE datasource. I changed the configuration to use the Glassfish datasource.

The Glassfish server now needs a datasource configuration, including the database driver implementation for hsqldb. By adding the jar to /opt/app/extlib, the driver is copied to the Glassfish lib directory – this makes it available for datasources.

The (in /opt/app/bin) script creates the necessary datasource:

asadmin create-jdbc-connection-pool --restype=javax.sql.DataSource --datasourceclassname=org.hsqldb.jdbc.JDBCDataSource \
 --property "user=sa:password=sa:url=jdbc\:hsqldb\:hsql\:mem\:petclinic" \
asadmin create-jdbc-resource --connectionpoolid PetClinicPool jdbc/petclinic

In the Dockerfile I add the hsqldb jar and the configure script:

ADD hsqldb-2.3.2.jar /opt/app/extlib/hsqldb-2.3.2.jar
ADD /opt/app/bin/

After building the Docker image, you can run Glassfish with the necessary configuration:

docker run --rm -it -v ~/tmp/glassfish/deploy:/opt/glassfish4/glassfish/domains/domain1/autodeploy \
 -v ~/tmp/glassfish/logs:/opt/glassfish4/glassfish/domains/domain1/logs \
 -p 4848:4848 -p 8080:8080 -p 9009:9009 \
 -e DEBUG="true" koert/glassfish-showcase

The “–rm” option instructs Docker not to keep the state of the started container, so you can start the image fresh every time. The “-it” option keeps the container running in the foreground – you can stop it with Ctrl-C.

While this is running, you can deploy your web application by copying its war or ear file to the ~/tmp/glassfish/deploy directory. You can debug the application by letting your IDE connect to port 9009.

This way you have a consist development environment with a well defined state.

Packaging a webapp with Docker and Glassfish

As I wrote in a previous article, you can run Glassfish in a Docker container.

The purpose of Docker is to package everything into a container so that you can run your application anywhere in a consistent state. To achieve this with a web application and Glassfish, you package the Java virtual machine (JDK 8), Glassfish 4.1 and your web application together.

I created an example of using my base Glassfish image with the Primefaces showcase war file:

FROM koert/glassfish-4.1
MAINTAINER Koert Zeilstra <>

RUN wget -O /opt/app/deploy/showcase.war

This will download the war file and put it into the /opt/app/deploy directory – the startup script will copy this file into the Glassfish autodeploy directory. When Glassfish starts up, it will automatically deploy the war and you can access the applciation after starting with:

docker run -d -p 8080:8080 koert/glassfish-showcase

On my laptop it starts up in about 12 seconds, you can look at the application in your browser: http://localhost:8080/showcase

Look at my example on Github: