Spring Boot application on Heroku

In this blog post I would like to demonstrate how easy is to deploy a simple Spring Boot application on Heroku.

• Sign up for a Heroku account
• Download the Heroku Toolbelt, which is tool to manage Heroku applications from command line
• Login to heroku and set up SSH keys

• Clone the sample app from my github account

• Build and verify that it starts up locally

• Configure the sample app as a heroku application and push it live

In the root folder of the sample application there is file name Procfile with the following content

This is needed to let Heroku know how to run the application. On Heroku we cannot tell explicitly on which port should the application run, this depends runtime based on the $PORT environment variable. Our sample application by default runs on 8080 port when starting it up with above command (in the Heroku specific Procfile). This can be easily changed with the server.port in the application.properties as seen below:

This way locally we can use the short command line arguments --port=9000 instead of --server.port=9000 and will also work on Heroku since Spring can bind to capitalized synonyms for Environment properties.
After you have finished stop your deployed application and logout from Heroku

A running version can be accessed here. Note that by default our application will use a single dyno (Heroku term for scaleable unit) and it will go to sleep after one hour of inactivity. This causes delay of a few seconds for the first request, subsequent requests will perform normally.

JAXB namespace configuration

In this blog post I would like to demonstrate how to configure a namespace in the XML messages used by REST endpoints. If you would rather jump right to a working example, have a look on my github account. Let's consider the following example message, where widgets can have different type of resources.

In the above example all XML elements belong to the "http://www.backbase.com/ns/widgets" namespace. This simple widget configuration message could have the following XSD:

In order to generate and consume these type of messages we create our model WidgetConfig and WidgetConfigRef.

With the namespace attribute of @XmlRootElement, @XmlElementWrapper and @XmlElement we configure the namespace on all XML elements found in the XSD. Note the use of @XmlElementWrapper, which is used to produce a wrapper XML element around resource elements. In order to set the namespace prefix (in this case "bb") we need the following:

Next we use Spring's excellent Object/XML Mapping support by defining a marshaller/unmarshaller as shown below:

And we are ready. A working example you can find on my github account. Note, if you are still using Java 6, you need to update the JAXB implementation by including the following dependencies. Otherwise the namespace prefixes will not be set. The JAXB implementation in Java 7 hasn't got this issue.

Playing with distributed percolator from elasticsearch

I have recently attended an elasticsearch meetup in Amsterdam, where I heard the first time about a very cool feature of elasticsearch, called percolator.
Using the percolator, you can register queries against one or multiple indices and then you can send percolate requests with a document which return which registered queries it matched.

The percolator has been available in the product since the version 0.15, however starting from version 1.0 a fully distributed version of percolator will be available. The redesigned percolator will have a _percolator type mapping instead of a _percolator index, and the query and data will coexist with the same index. The redesigned percolator is also fixing the confusing part of the query registration API where the index name was represented as the type in the _percolator index. In the redesigned percolator this confusion is gone, because the _percolator became a type

There are many use cases for percolator. For example in case or a real estate website, registered users save their preferences (a query) about their dream house which they want to buy. When a new house is added to the website, a notification is sent to the registered users if there is match with their preferences (using percolate requests).
Let's consider the following model

Since automatic mapping of "geo enabled" properties has been disabled, you have to provide the correct mapping for geo properties. For the sake of simplicity XContentBuilder, a built-in utility from elasticsearch, is used to construct the JSON representation of the model. Another alternative would be to use Jackson.

Let's consider that one user is interested in houses within 5km of Utrecht central station prices between 250000 and 300000. We could have the following filter

Using the above filter we can register the following query. The user id is saved in this query, in order to know to which user it belongs.

When a new house is added then we can a send percolate request with the new document. Note that the new document is not added to the index.

If there was a match we need to check to which user the query belongs in order to send notification.

A working example you find on my github account. In order to try it, you need to clone elasticsearch and build it locally, since the redesigned percolator will be available in the 1.0 release.

Modularising Spring's Java-based configuration

When using Spring's XML based configuration it is a good approach to modularise the configuration with the <import/> element. For example with a JPA repository configuration there can be an infrastructure configuration for setting up the LocalContainerEntityManagerFactoryBean and JpaTransactionManager

Using the above, not application specific configuration, we can create an application specific repository configuration

The above modularisation can be easily achieved also using Spring's Java-based configuration. The @Import annotation can import other configuration classes.

Besides @Import, the @ImportResource can be used to import configuration from XML files. You can mix the XML and Java configuration this way, although I do not recommend doing that. Similar to using XML or Java for DI configuration the my recommendation is that together with your team you decide which approach to use and stick to it, otherwise maintenance work will be much more difficult.


Note that Spring requires CGLIB to support Java configuration classes. Starting from Spring 3.2 explicit dependency on CGLIB is no longer required, because it is repackaged and inlined into the framework.

For a working example you can have a look at my github account.