Create Java+Tomcat language pack to run Java web applications

Bug #1358462 reported by Devdatta Kulkarni on 2014-08-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

We want Solum to run Java web applications on Tomcat application container. This bug is regarding creating a Java+Tomcat language pack which would allow Solum to do this.

High-level Details:

Given a repository containing Java code, we want Solum to:
- create a war file
- deploy the war file to Tomcat
- start the application

One approach to achieve this is to build a Java+Tomcat language pack which application developers can specify in their plan files while working with Java applications. The language pack would contain latest versions of JDK, JRE, Maven and Tomcat. As documented in the custom-language-pack spec, we will create a repository with the Dockerfile containing commands to install latest versions of these. We also want Tomcat to start when the container is spun up. Towards this we will include the Tomcat start up command within the Dockerfile.

Once this language pack is available in Glance, application developers would use it as follows:

1) Specify this language pack in their plan file
2) As part of build-app execute the following steps/commands within the context of the language pack (i.e. by spinning up the language pack container)
  2.1) Git clone the repository (git clone <java-repo>)
  2.2) Spin-up container and inject the application source code into it
  2.3) Build the war file (mvn clean compile)
  2.4) Copy the war file to appropriate location (cp <path to app.war> to <path to Tomcat webapps directory>)
  2.5) Snapshot the container image
  2.6) Upload it to glance

Steps 2.1, 2.2, 2.5, 2.6 are already being done by Solum (see build-app script).

For steps 2.3 and 2.4 we propose to modify the plan file to contain a new attribute (build_cmd) whose value would be a script that the application developer would need to provide in their application repository. Solum would then execute this script as part of the 'build-app'. For example here is a plan file for a Java

version: 1
name: chef
description: sample java application
- name: Java test application
  artifact_type: Java
    href: <git path to sample Java web application>
  language_pack: java_maven_tomcat
  build_cmd: ./

Here we propose that '' be provided by the application developer. This script may contain following commands:
- mvn clean compile (build the war file)
- cp ./WEB-INF/target/*.war <path to tomcat webapps directory>

Other aspects to consider:
Q) Can we use Cloudfoundry's Java buildpack (

A) Need more investigation.

Adrian Otto (aotto) wrote :

Are existing Java Buildpacks not suitable?

For example, what about:

Changed in solum:
status: New → Incomplete

We need investigation to check whether existing Java buildpacks, such as the one from CloudFoundry, can be used or not.
I have identified this under 'Other aspects to consider' section towards the end of the bug report.

Okay, I have started looking at CF Java buildpack. Will come back with information about:
- can it be directly used within Solum
- if not, what is required

Good reference:

I have completed the investigation. Here is the analysis.

It is possible for Solum to directly leverage CF Java build pack (and probably other CF build packs as well). For this, what we need is an 'interpreter' that is able to execute the 'detect', 'compile', and 'release' steps of the Java buidpack. Such an interpreter does not have to be part of Solum per se. It could be part of a Docker container that we would use in Solum. This is how Solum currently support Heroku buildpacks.

CF Java build pack supports three kinds of components -- containers (Tomcat, Play, etc.), jres (openjdk, oracle), and frameworks (jdbc, newrelic, etc.). The primary responsibility of each component is to determine whether, it is applicable to a given application and if so, prepare the application for release. Such determination and preparation for release is accomplished via three phases that each component implements. These are, 'detect', 'compile', and 'release'. Developer of a component is responsible for implementing these interfaces/methods. These methods also form the contract between CF and the component.

When an application repository is passed to CF, it tries the 'detect' step of all the components and picks the first one which is applicable. It then invokes the 'compile' and 'release' steps of that particular component. A buildpack is made up of n such components (c containers, j jres, and f frameworks).

So for Solum to be able to directly use CF build pack, Solum needs to implement the CF-side of contract.

One way to do this is to create a Docker container that has this CF 'interpreter' embedded in it. For reference, see the 'builder' script in progrium:

Look at lines 39-41.

Progrium provides the basic interpreter for heroku buildpacks, which also implement a contract that is similar to CF buildpack contract. In lines 39-41, we see that the interpreter is iterating through the list of buildpacks and calling 'detect' on each.
Currently Solum's 'cedarish' language pack uses progrium's Docker container as the starting point. That is how Solum is able to support Heroku buildpacks.

We will need something similar for handling CF buildpacks.

Changed in solum:
assignee: nobody → Gilbert Pilz (gilbert.pilz)

This has been completed.

Solum's custom languagepack feature is able to support creation of Java languagepacks.

Changed in solum:
status: Incomplete → Fix Committed
assignee: Gilbert Pilz (gilbert.pilz) → nobody
importance: Undecided → High
Changed in solum:
milestone: none → 2015.1.1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers