Using Spring for REST on Liberty Buildpack

8 min read

Using Spring for REST on Liberty Buildpack

During a recent development sprint our team was investigating frameworks in place to support Social Login for a RESTful application.  In our research, we found that the common social login areas we were looking at Twitter, Facebook and Google all provided solid documentation on how to integrate into an application.

As we dug deeper to find previous artifacts and frameworks that we could take advantage of, we found Spring Social as one of the Spring Projects.   It has core support for both Twitter and Facebook and linked to a community project for Google Social.

All of our previous RESTful implementations on Liberty Buildpack had used JAX-RS and we have found using that framework simple and powerful.  The annotations were simple and for the most part our apps were simple enough to utilize just that and be successful.

As a team, we discussed if we wanted to mix JAX-RS and Spring Social, or did we set this project up with Spring REST and use one set of annotations. It’s important to note here that you can very much combine both Spring and JAX-RS, our decision was primarily being made based on code style and developer convenience rather than technical factors.

Setting up a Sprint REST app

One of the many attractions we had with JAX-RS was the simplicity of setting up and RESTful providers and associated methods for handling GET, POST, PUT and DELETE requests; annotate the method and done. Spring REST, unsurprisingly, does it the same way. Below you can see the annotations on a JAX-RS class and how that maps to the Spring annotations to achieve the same goal.


public class PreferencesProvider {<br>
public Response getPreferences(@PathParam(“text”) String text) {<br>
return Response.ok(text);<br>
Spring REST<br>
public class PreferencesProvider {<br>
@RequestMapping(value = "/{text}", , method = RequestMethod.POST)<br>
public ResponseEntity&lt;?&gt; getPreferences(@PathVariable String text) {<br>
return ResponseEntity.ok(text);<br>


As you can see, from a code perspective, there isn’t much of a change to the general approach; the annotations are different but their use is obvious.

The real difference is how you then tell Spring to activate the application as a RESTful app.

Setting up web.xml

If you had previous experience with JAX-RS you will be familiar with the following web.xml fragment:



This provided the info to liberty as it loaded the war, it told it the context path to use and then said “hey I am JAX-RS” and the code scan of the annotations then loaded in the appropriate providers.

Spring isn’t a million miles away from this, however the approach is a little different.

The web.xml looks like this:

&lt;?xml version="1.0" encoding="UTF-8"?&gt;&lt;web-app xmlns="" xmlns:xsi="" version="3.0" xsi:schemaLocation=""&gt;<br>


Then, along with web.xml, we add a spring-servlet.xml into the WEB-INF directory of your project:

&lt;beans xmlns=""<br>
<p>&lt;context:component-scan base-package="" /&gt;<br>
&lt;mvc:annotation-driven /&gt;</p>


The context:component-scan tag tells spring where to go find components with the annotations.  You should set the base-package attribute to the name of your package in your war file.

Deploying to Bluemix

Now, as always with bluemix, the easy part; the deployment.  Build your war and push to bluemix with either the Bluemix CLI or the Dev Ops tools.


We are deploying our apps with gradle, for reference here is our gradle build file in case the dependencies prove useful.  You can start the with the web-starter-boot from spring but our dependancies just list what is needed for Spring REST to work.

buildscript {<br>
repositories {<br>
dependencies {<br>
<u>classpath</u> "org.springframework.boot:spring-boot-<u>gradle</u>-<u>plugin</u>:1.5.7.RELEASE"<br>
<p>apply <u>plugin</u>: 'java'<br>
apply <u>plugin</u>: 'eclipse'<br>
apply <u>plugin</u>: 'idea'<br>
apply <u>plugin</u>: 'org.springframework.boot'<br>
apply <u>plugin</u>: 'war'</p>
<p>war {<br>
baseName = 'NameOfYourApp'<br>
version =  '0.0.1'<br>
<p>repositories {<br>
<p>sourceCompatibility = 1.8<br>
targetCompatibility = 1.8</p>
<p>dependencies {<br>
compile group: 'org.springframework', name: 'spring-core', version: '4.3.11.RELEASE'<br>
compile group: 'org.springframework', name: 'spring-context', version: '4.3.11.RELEASE'<br>
compile group: 'org.springframework', name: 'spring-beans', version: '4.3.11.RELEASE'<br>
compile group: 'org.springframework', name: 'spring-expression', version: '4.3.11.RELEASE'<br>
compile group: 'org.springframework', name: 'spring-web', version: '4.3.11.RELEASE'<br>
compile group: 'org.springframework', name: 'spring-<u>webmvc</u>', version: '4.3.11.RELEASE'<br>
compile group: 'org.springframework', name: 'spring-<u>aop</u>', version: '4.3.11.RELEASE'<br>
compile group: 'org.springframework', name: 'spring-context', version: '4.3.11.RELEASE'<br>
compile group: 'com.fasterxml.jackson.core', name: '<u>jackson</u>-core', version: '2.9.1'<br>
compile group: 'com.fasterxml.jackson.core', name: '<u>jackson</u>-annotations', version: '2.9.1'<br>
compile group: 'com.fasterxml.jackson.core', name: '<u>jackson</u>-<u>databind</u>', version: '2.9.1'<br>
compile group: 'org.slf4j', name: '<u>jcl</u>-over-slf4j', version: '1.7.25'<br>


We hope this is a useful starter for getting Spring REST up and running on the liberty buildpack, as we said before we don’t see a huge difference between Spring and JAX-RS in terms of ease of development it was more a developer familiarity choice.  Moving our code to spring certainly allows us to take advantage of the other areas of usefulness that spring provides.

Be the first to hear about news, product updates, and innovation from IBM Cloud