Deploying a web application (war) into a vagrant container using ansible

At the moment, the showcase application for my web application framework is hosted in the AWS cloud using the AWS Beanstalk service (as described in this post). Unfortunately my free usage period for the Amazon services timed out and despite the really great and easy way to deploy web applications using Beanstalk, the monthly fee of about ~70$ for a micro EC2 instance and a micro mysql instance are to high just to host a small showcase application. Luckily at home I have a HP Proliant Microserver that is already running 24/7 serving as NAS and has enough power to host the showcase. To increase portability and to make it possible to play around with the showcase on your local machine the new solution is based on a Vagrant (using Virtualbox as backend) and ansible to provsion the system.

The Vagrantfile defining the box is pretty straightforward, an Ubuntu 14.10 base system (Tomcat 8 is only available in the Ubuntu repositories after 14.10) and a port forward to make the Tomcat available from the outside. The synced_folder directive suppresses the default shared folder that is not needed here and the vb.customize statements increase the memory and CPU values for the box. The interesting part starts with the declaration of the provisioner for this box. I chose ansible this time (the previous versions of the showcase were deployed by salt and puppet) because of its simple and agentless architecture which leads to relatively fast results (in this simple usecase).

The playbook file is the entry point for ansible to look for its configuration. The idea of this particular playbook is to install Tomcat 8 (using a custom configuration file that includes the JDNI link definitions for my web application

The server.xml looks like this:

Now after Tomcat is installed we need the war file and of course that JDBC driver for the JNDI link (in this case an embedded Derby database). Because everything is available in maven repositories and I really don’t like maven I use gradle to fetch all dependencies and place them in a single folder. This is how the gradle build file looks

In the ansible playbook the gradle build file as well as the gradle wrapper are copied into the vagrant box and executed.

The wrapper frees us from installing gradle:

The Gradle Wrapper (henceforth referred to as the “wrapper”) is the preferred way of starting a Gradle build. The wrapper is a batch script on Windows, and a shell script for other operating systems. When you start a Gradle build via the wrapper, Gradle will be automatically downloaded and used to run the build. now that gradle has fetched all needed dependencies, just copy the war file and the JDBC jar into the right folders:

and restart tomcat:

And after a few moments tomcat happily serves our web application on port 8080. For completeness here the full playbook (the installation of the python-apt package is a hack due to a bug in the base image and normally not necessary):

So to deploy a new version of the showcase a simple vagrant destroy -f && vagrant up recreates the box which is from now on reachable at

The only downside of this solution is, that the hosting moved from here:


to here:


But on the upside, the NSA will never find my server =).

By |April 10th, 2015|linux|

I still don’t get it…

Because I had to explain to a few people what exactly the goal of the framework I’m working on is, I created a small “product page” that sums up the most important features: Feel free to contact me on Hangout/Google+/Mail if you have more questions.

By |April 6th, 2015|development|

New Feature: Application Properties

Mangos properties features enables you to equip your application with configuration options. Parameterization is supported from the command line using Java system properties, using Spring properties from the application context and of course from the database. The properties are defined using a Java based DSL and support features like fallback to other properties if undefined, default vales and a web interface to change properties live in the frontend.

See below for some code examples or here for full documentation.

Simple string database property

Setting default values

Useful defaults for your properties can be defined using the default(...) method.

Fallback to another backend.

Fallback to another backend using the same property key is configured using the database(), system() or spring() methods.

Fallback to another property

It is also possible to fallback to another property (of the same type) using the fallback(...) method.

Adding properties to the web UI

To activate the web UI add the module to your navigation tree.

Then in your client code add your properties to the PropertyProvider. Properties can be grouped logically into categories which will display them in separate tabs in a tabfolder.


By |April 5th, 2015|mango|

Jenkins walldisplay version 0.6.29

It has been some time since the last Jenkins walldisplay plugin release, thanks to numerous contributors a bunch of new features and bugfixes have been added in the meantime:

  • Bug fix – JENKINS-26873 Sorting by Status does not work correctly
  • Bug fix – JENKINS-26745 : fix javascript error on undefined object
  • New Feature – The gravatar URL can now be configured in the plugin configuration
  • New Feature – The Junit result display can be switched of now
  • New Feature – Jenkins display name feature is used for job name display

A screenshot of the configuration page for the plugin shows most of the current features: walldisplay_0.6.29_1

See here for a live Demo or the screenshot below for the current state:

Jenkins Wall Display  All

By |March 25th, 2015|development, jenkins|

Jenkins GitHub issue updater

For GitHu hosted project that is continuously built using Jenkins I needed the build number in every GitHub issue that was mentioned in the commits that were part of the build, or in other words:

“Scan the commit comments for numbers and check on GitHub if these numbers refer to an issue. If so comment the issue with build information from the running build.”

Quite unusually for Jenkins I couldn’t find a plugin performing this task but thankfully to Jenkins and GitHubs public APIs this problem was easy to solve. The following script need information about the Jenkins server (which build, what build number, etc.) and the GitHub user and repository to match against. Because the script is meant to be run within a Jenkins build, it tries to determine the Jenkins server url, job name and build number from the well known Jenkins environment variables (JENKINS_URL, JOB_NAME and BUILD_NUMBER). An optional security token as well as all GitHub information can be passed as command line parameter, call the script with --help for a overview of the parameters:

help output

If invoked the script will dump its configuration (without the security tokens) and log some information while parsing the commit messages:

example script run

The source code is available on GitHub in form of a gist:

By |March 9th, 2015|development, jenkins|

Mango persistence services

Because Mangos persistence services may not be self explaining on the the first glimpse this post tries to put some light into this topic:

Two low level services provide basic persistence functions for entities/value objects, the IBaseEntityDAO for entities and the IBaseVODDAO for value objects (these two are nearly identical, in fact they are derived from the same basic service interface just with different generic types for entities/value objects).

The IBaseVODAO internally copies the data from/to the entity/value object using the copy service. Despite the fact that one the server you are free to use entities/value objects or both, it is advisable to always use the value object based IBaseEntityService as you would from any client side code. The IBaseEntityService provides some higher level persistence functions as well as validation based on the datatype metadata.


As IBaseEntityDAO and IBaseVODDAO provide generic persistence functionality for all entities or value objects you may want to add specialized persistence behavior for your own entities or value objects. This can be achieved be registering an entity/value object specific EntityDAO/VODAO.

For each entity an basic Base{entity name}EntityDAO/Base{entity name}VODAO is generated. This default implementation defaults to the normal entity/value object DAO behavior. You can override this default implementation to add your own business logic.

entity DAO example

To create a new entity specific DAO extend the generated BaseDAO for the entity:

and register the DAO in your Spring application context:

By |March 5th, 2015|development, gwt, mango|

The Mango framework in three minutes

A screencast showing the key features of the Mango framework for web applications in three minutes.

By |February 25th, 2015|development, gwt, mango|

New feature: Entity webhooks

Mango already offers numerous APIs (SOAP Webservices, REST and plain XML) to access the data contained in an application but to get the data you have to actively ask the application for the data. A new feature resembling the well known webhooks from Github lets you register callback URLs that get triggered with HTTP post requests when certain events occur, for example the creation of a new country entity.

From Wikipedia

Webhooks are “user-defined HTTP callbacks”. They are usually triggered by some event, such as pushing code to a repository or a comment being posted to a blog. When that event occurs, the source site makes an HTTP request to the URI configured for the webhook. Users can configure them to cause events on one site to invoke behavior on another.
Webhooks can be either registered using a REST Api or alternatively using a UI that is included in Mango.

example entity webhook registration

When a webhook is triggered for example when a new entity is created, the request body of the following post request to the webhook URL looks like this:

example request body for an entity ON_CREATE webhook event

list entity webhooks example

delete entity webhook example

Of course all of the above can also be done using the webhook UI webhook UI mango_entity_webhooks1

A running example is as always contained in the Showcase, more information in the documentation.

By |February 18th, 2015|development, gwt, mango|

New feature: Entity REST API

A still experimental but already working feature is the entity REST API. For all modeled entities a REST API is generated supporting the retrieval of entities by id/natural key or even a custom query. The API overview page is can be reached from the entity editor.

API overview page mango_entity_api1

load by id example

$ curl
"id": 1,
"countryIsoCode2": "AF",
"countryIsoCode3": "AFG",
"countryRating": null,
"countryName": "Afghanistan",

load by natural key example

$ curl
"id": 1,
"countryIsoCode2": "AF",
"countryIsoCode3": "AFG",
"countryRating": null,
"countryName": "Afghanistan",

load by query expression example

To load more than one entity you can use a query to match the entities send as query parameter {baseUrl}/query?query={query} or as content of the HTTP request. The expression is based on the Spring Expression Language (SpEL).

// query = countryName matches 'a%' $ curl


p>[ { "id": 1, "countryIsoCode2": "AF", "countryIsoCode3": "AFG", [...] }, { "id": 6, "countryIsoCode2": "AS", "countryIsoCode3": "ASM", [...] }, { "id": 7, "countryIsoCode2": "VI", "countryIsoCode3": "VIR", "countryRating": null, "countryName": "Virgin Islands, U.s.", [...] } ]

An small page listing all relevant URLs for each entity that also includes a minimal REST client to try the API right away is automatically provided.

API index page example mango_entity_api2

You can try out the country API from the showcase application at:

By |February 11th, 2015|development, gwt, mango|

Jenkins walldisplay version 0.6.28

Time for a new Jenkins walldisplay release, version will be 0.6.28 and should show up in the Jenkins repository within the next few hours. This release contains the following changes (nearly 100% from Github pull request, thanks to all comitters):

  • JENKINS-25022 Walldisplay is not shown, if the project has the same name as the current view (thanks to
  • only show “Loading jobs…” in debug mode
    displaying the loading jobs message clears the whole screen from all jobs.
    this commit only displays the message when in debug mode which results
    in a better user experience when not in debug mode. (thanks to linki)
  • JENKINS-23620 Screen repaint without disturbing glitches (thanks to pvelder)
  • Support showing Junit results in the wall whenever available (both thanks to jaby)


By |January 30th, 2015|development, jenkins|