Monday, January 24, 2011

Case study about our experience with SpringRoo

The TomTom Case Study shares our experience with Spring Roo while working on the TomTom Road Report project.

...The initial goal was to only use Spring Roo to develop the prototype as fast as possible…We decided it would be a good decision to keep using Spring Roo for our production application, so that we could benefit from the productivity it gave us to maintain the application in the future.

...Many technologies that I would not have contemplated adding to the application, because of time constraints, are now possible…Spring Roo gives me more freedom to experiment with various technologies.

Sunday, November 07, 2010

Publishing SpringRoo Addons with the central addon repository - RooBot

I have registered all Spring Roo Addons I have created so far with the central OBR repository (RooBot). Now you can install them directly from your roo shell!

http://twitpic.com/34t1j3

Tuesday, October 05, 2010

Create Executable Wars with Spring Roo

Executable War Addon project:http://code.google.com/p/spring-roo-addons

Update (19.01.2012): installation instructions slightly updated to reflect the new Roo 1.2.0 compatible release

Update (12.11.2010): installation instruction changed to allow installation directly from the roo command line

You can turn your web application into a self-contained executable war that can be run from the command line: or deployed in web container.

For this you need to embed a lightweight Servlet container (Jetty, Winston) inside the WAR and provide a java main class to bootstrap it. This approach has already been discussed in blogs like Executable WARs with Jetty, Executable war file that starts jetty without maven (google for "executable war" to find more).

Based on Jetty and maven-assembly-plugin I have implemented Excutable-War Roo addon that can extend your maven project configuration to allow generation of executable wars. Short instructions of how to install and use the addon are provided below.
The current addon version is Roo 1.2.0 compatible. The Roo 1.1.x compatible version is net.tzolov.jetty.executable.war.roo.addon;1.0.0

1. Install the executable-war addon:

Verify success via osgi ps and look for an entry at the bottom such as:

2. Create a simple Roo web project

3. Apply the addon

This adds a new ExecWar.java main class to your project's top level package (This class starts the embedded jetty with your application deployed inside). The setup also adds or updates your maven-assembly-plugin with execwar.xml configuration.

4. Create the executable war

(or you can run it from the command line as maven goal: mvn assembly:assembly). The result is an execwar.smaple-EXECWAR.war file in your target folder

5. Start the application form the command line

Now you can access the application at: http://localhost:8080/. Also you can specify the -Dport=8888 and the -Dpath=myapp system properties to change the port and the context path of the application.

Sunday, September 19, 2010

"Server Side Java Development Using Spring Roo" - Slides from my presentation at GeeCon 2010

The slides from my presentation at GeeCon 2010 conference are available at: Rapid Server Side Java Development Using Spring Roo

This presentation is about rapid development of a Java web application that aggregates and manages web services. For this we use the Spring Roo framework in order to gain productivity while still using the well known Java APIs and technologies. Productivity in building prototypes in the early stage is crucial for the success of the agile development process used in TomTom. Our practical experience in applying Spring Roo in various TomTom projects will be shared while walking you through the implementation of a simple Traffic Jam Information Service.

Monday, May 10, 2010

Spring Roo Addons : JAXB2 binding and Content Negotiation Support


Update: (23.05.2011) The Roo-1.1.4 (and newer) requires the 'web mvc setup' command to be executed before the 'controller class'. Remove all Roo-1.0.2 related content.

Update: (07.11.2010) The 1.1.4 version of the Jaxb and the Http Representation addons have been released. This version is Roo 1.1.0.RELEASE compatible and is registered with the central OBR repository (RooBot). Now you can install them directly from your Roo shell!


Several of the RESTful java projects I am working on have similar toolchain requirements. They all need an XML binding mechanism (Maven2 JAXB 2.x XJC Pluginjavascript:void(0)) and support for different content type representations (html/jsp, xml and json to be precise) using the Content Negotiation View Resolver.

Instead of copy&paste the same configurations across multiple projects I have created the following two Spring Roo 1.1.x addons: jaxb-addon and http-representation addon. (they are part of the http://code.google.com/p/spring-roo-addons/ project)

The following tutorial demonstrates how to use the new addons. It requires Maven, Java 1.6. Also you should have the above addons (jaxb-addon and http-representation addon) installed before you continue.

1. Create a new 'demo' project

The jaxb xsd command (line 5) installs the jaxb/xjc maven plugin in your project's pom.xml. Note that the generate directory is set to: src/main/java!

2. Add the following example people.xsd schema file to your src/main/resources directory:

Re-build the project and you should be able to see the Java classes generated in the src/main/java directory.

3. Create the PeopleController

3.1 Add the getPeople method (shown below) to the PeopleController. On requests this method creates new Person instance and puts them in the modelMap.


Update (21.06.2010): Added the imports declaration to the code snipped below

3.2. Add the following jsp fragment to your src\main\webapp\WEB-INF\views\people\index.jspx to visualize the people list:

Note: define the core JSTL namespace:

4. Deploy your application and access the people resource at: http://locahost:8080/demo/people/index. You should see the html representation of the people list.

5. Final step is to enable the XML and JSON representations for the people resource.

  • Line 1 generates all boilerplate code including the content negotiation resolver configuration and the configurations of the Jackson-Json and Jaxb marshallers. For details check the src\main\resources\META-INF\spring\applicationContext-contentresolver.xml. It is important to mention that the Jackson  object mapper is configured to use the jaxb annotations. So the JSON format produced will confirm to the people.xsd schema. Contract First :)
  • Line 3 adds the People class to the list of jaxb marshaller. Note that you should have the xsd generated classes in the classpath of the Roo (this is the reason we generated them in the src/main/java). Alternatively you can add the classes directly in the context file.

Now you can use *.xml to obtain the XML (http://locahost:8080/demo/people/index.xml) representation and *.json for JSON (http://locahost:8080/demo/people/index.json) representation of the People resource.

Zipped backup of the entire demo project is available at: demo_2010-05-10_11.07.17.zip

Enjoy!

Sunday, March 14, 2010

Thursday, March 04, 2010

Spring 3 - RestTemplate - Access to Request Headers

The RestTemplate is a recent addition to the Spring framework coming with the Spring @MVC 3.0.x. It provides a RESTful service access mechanism implemented in a way similar to the other Spring template classes. The reference documentation and this bolg provide a good overview of the RestTemplate capabilities.

Unfortunately the current implementation does not provide an easy way to set http request headers with the RestTemplate's GET and POST methods. This is a known issue and is to be resolved in Spring 3.1.

In the meantime you can use the following simple decorator class (RestTemplateExt) that extends the original RestTemplate and provides access to the request http headers via the getRequestHttpHeaders() method.



With this approach you can pre-set some header values with a single RestTemplateExt instance and send them on every http method call. If different header sets are required by the different http methods then you may have to create separate RestTemplateExt instance for each http method.