In a previous post, RESTful services with jQuery and Java using JAX-RS and Jersey, I demonstrated how to build a RESTful API using JAX-RS and Jersey, and how to build a jQuery application that leverages that API. The application used as an example was a Wine Cellar management application.

In follow-up posts, “Backbone.js Wine Cellar Tutorial” (part1, part 2, part 3), I showed how to add structure to the client-side of the Wine Cellar application using Backbone.js. But that three-part tutorial was provided with a PHP back-end.

By popular demand, here is a version of the Backbone.js Wine Cellar application powered by a Java / JAX-RS back-end using Jersey. The server-side of the application provides an example of building a complete RESTful API in Java using the different HTTP methods:

• GET to retrieve and search wines
• POST to add a wine
• PUT to update a wine
• DELETE to delete a wine

As already mentioned, the client-side of the application provides an example of adding structure to your JavaScript code using the Backbone.js Model, View and Router components. To learn more about the Backbone.js implementation, refer to the three part tutorial mentioned above: it is entirely back-end agnostic.

The source code for this application is hosted on GitHub here. It consists of the Eclipse Dynamic Web Project with the source code for both the Java back-end and JavaScript/Backbone.js client.

You can run the application (Part 3) here. The create/update/delete features are disabled in this online version.

Follow @ccoenraets

This is a more in depth version of my previous post on the same topic. The previous article only covered the HTTP GET method for building RESTful services. This article (and its new companion app) provides an example of building a complete RESTful API using the different HTTP methods:

• GET to retrieve and search data
• POST to add data
• PUT to update data
• DELETE to delete data

The application used as an example for this article is a Wine Cellar app. You can search for wines, add a wine to your cellar, update and delete wines.

You can run the application here. The create/update/delete features are disabled in this online version. Use the link at the bottom of this post to download a fully enabled version.

The REST API consists of the following methods:

Implementing the API using JAX-RS

JAX-RS makes it easy to implement this API in Java. You simply create a class defined as follows:

package org.coenraets.cellar;

@Path("/wines")
public class WineResource {

	WineDAO dao = new WineDAO();

	@GET
	@Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
	public List<Wine> findAll() {
		return dao.findAll();
	}

	@GET @Path("search/{query}")
	@Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
	public List<Wine> findByName(@PathParam("query") String query) {
		return dao.findByName(query);
	}

	@GET @Path("{id}")
	@Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
	public Wine findById(@PathParam("id") String id) {
		return dao.findById(Integer.parseInt(id));
	}

	@POST
	@Consumes({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
	@Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
	public Wine create(Wine wine) {
		return dao.create(wine);
	}

	@PUT @Path("{id}")
	@Consumes({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
	@Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
	public Wine update(Wine wine) {
		return dao.update(wine);
	}

	@DELETE @Path("{id}")
	@Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
	public void remove(@PathParam("id") int id) {
		dao.remove(id);
	}
}

Quick look at the JAX-RS annotations used in this class:

• @GET, @POST, @PUT, @DELETE: HTTP method the class method responds to.
• @Path: path the method responds to.
• @Consumes: type of data the method can take as input. The data will automatically be deserialized into a method input parameter. For example, you can pass a wine object to the addWined() method either as JSON or XML. The JSON or XML representation of a new wine is automatically deserialized into the Wine object passed as an argument to the method.
• @Produces: One or more response content type(s) the method can generate. The method’s return value will be automatically serialized using the content type requested by the client. If the client didn’t request a specific content type, the first content type listed in the @Produces annotation will be used. For example, if you access http://coenraets.org/rest/wines, you get a list of wines represented as JSON because it is the first content type listed in the @Produces annotation of the findAll() method.

The jQuery client below sends data to the server using JSON (addWine() and updateWine() methods).

The approach you use to actually retrieve the data is totally up to you. In this example, I use a simple DAO, but you can of course use your own data access solution.

Testing the API using cURL

If you want to test your API before using it in a client application, you can invoke your REST services straight from a browser address bar. For example, you could try:

• http://localhost:8080/cellar/rest/wines
• http://localhost:8080/cellar/rest/wines/search/Chateau
• http://localhost:8080/cellar/rest/wines/5

You will only be able to test your GET services that way, and even then, it doesn’t give you full control to test all the content types your API can return.

A more versatile solution to test RESTful services is to use cURL, a command line utility for transferring data with URL syntax.

For example, using cURL, you can test the Wine Cellar API with the following commands:

• Get all wines returned as default content type:

  curl -i -X GET http://localhost:8080/cellar/rest/wines
  

• Get all wines returned as xml:

  curl -i -X GET http://localhost:8080/cellar/rest/wines -H 'Accept:application/xml'
  

• Get all wines with ‘chateau’ in their name:

  curl -i -X GET http://localhost:8080/cellar/rest/wines/search/chateau
  

• Get wine #5:

  curl -i -X GET http://localhost:8080/cellar/rest/wines/5
  

• Delete wine #5:

  curl -i -X DELETE http://localhost:8080/cellar/rest/wines/5
  

• Add a new wine:

  curl -i -X POST -H 'Content-Type: application/json' -d '{"name": "New Wine", "year": "2009"}' http://localhost:8080/cellar/rest/wines
  

• Modify wine #27:

  curl -i -X PUT -H 'Content-Type: application/json' -d '{"id": "27", "name": "New Wine", "year": "2010"}' http://localhost:8080/cellar/rest/wines/27
  

The jQuery Client

Accessing your API through cURL is cool, but there is nothing like a real application to put your API to the test. So the source code (available for download at the end of this post) includes a simple jQuery client to manage your wine cellar.

Here is the jQuery code involved in calling the services:

function findAll() {
	$.ajax({
		type: 'GET',
		url: rootURL,
		dataType: "json", // data type of response
		success: renderList
	});
}

function findByName(searchKey) {
	$.ajax({
		type: 'GET',
		url: rootURL + '/search/' + searchKey,
		dataType: "json",
		success: renderList
	});
}

function findById(id) {
	$.ajax({
		type: 'GET',
		url: rootURL + '/' + id,
		dataType: "json",
		success: function(data){
			$('#btnDelete').show();
			renderDetails(data);
		}
	});
}

function addWine() {
	console.log('addWine');
	$.ajax({
		type: 'POST',
		contentType: 'application/json',
		url: rootURL,
		dataType: "json",
		data: formToJSON(),
		success: function(data, textStatus, jqXHR){
			alert('Wine created successfully');
			$('#btnDelete').show();
			$('#wineId').val(data.id);
		},
		error: function(jqXHR, textStatus, errorThrown){
			alert('addWine error: ' + textStatus);
		}
	});
}

function updateWine() {
	$.ajax({
		type: 'PUT',
		contentType: 'application/json',
		url: rootURL + '/' + $('#wineId').val(),
		dataType: "json",
		data: formToJSON(),
		success: function(data, textStatus, jqXHR){
			alert('Wine updated successfully');
		},
		error: function(jqXHR, textStatus, errorThrown){
			alert('updateWine error: ' + textStatus);
		}
	});
}

function deleteWine() {
	console.log('deleteWine');
	$.ajax({
		type: 'DELETE',
		url: rootURL + '/' + $('#wineId').val(),
		success: function(data, textStatus, jqXHR){
			alert('Wine deleted successfully');
		},
		error: function(jqXHR, textStatus, errorThrown){
			alert('deleteWine error');
		}
	});
}

// Helper function to serialize all the form fields into a JSON string
function formToJSON() {
	return JSON.stringify({
		"id": $('#id').val(),
		"name": $('#name').val(),
		"grapes": $('#grapes').val(),
		"country": $('#country').val(),
		"region": $('#region').val(),
		"year": $('#year').val(),
		"description": $('#description').val()
		});
}

Download the Source Code

The source code for this application is hosted on GitHub here. And here is a quick link to the project download (Eclipse Dynamic Web Project). It includes both the Java and jQuery code for the application.

UPDATE (1/11/2012): A version of this application using Backbone.js at the client-side is also available on GitHub here. You can find more information on the Backbone.js of this application here.

I’m interested in your feedback. Let me know what you think and what your experience has been building RESTful-based applications using Java and jQuery.

Follow @ccoenraets

• /rest/employees — Returns all employees
• /rest/employees/1 — Returns an employee identified by id (employee 1 in this case)
• /rest/employees/1/reports — Returns direct reports of an employee (employee 1 in this case)

In this post, I share a simple client application that uses these services to provide a basic User Interface for the application. The client is built with jQuery and uses JSON as the data exchange format.

Accessing the JAX-RS REST services using jQuery is easy. For example, here is the function used to retrieve and display a list of employees:

function getEmployeeList() {
	$.getJSON('http://localhost/directory/rest/employees', function(data) {
		$('#employeeList li').remove();
		var employees = data.employee;
		$.each(employees, function(index, employee) {
			$('#employeeList').append(
				'<li><a href="employeedetails.html#' + employee.id + '">'
				+ employee.firstName + ' ' + employee.lastName + ' ('
				+ employee.title + ')</a></li>');
		});
	});
}

Retrieving the data “Ajax-style” has many benefits:

• Your UI code doesn’t have a dependency on a specific server-side technology.
• Your data access logic doesn’t have a dependency on a specific UI technology.
• You can manipulate the data on the client side (i.e. sort using different criteria) without reloading the page.
• That decoupled architecture also works offline when working with a local database.
• You don’t have to reload a page to change the data it displays.

As an illustration of the last bullet, the application uses the “employeedetails.html” page to navigate up and down the org chart (when the user clicks on an employee’s manager link or on one if his/her direct reports). When that happens, the application just loads another employee object in the same page without reloading it.

Run the Application

Click here to run the application. The UI is intentionally plain. I’ll provide a more sophisticated UI in my next post.

Download the Source Code

Click here to download the source code (full Eclipse dynamic web project) or here to download the html and js files only.

Follow @ccoenraets

Configuring Tomcat (or your own app server)

There are many options to initialize Jersey in your servlet container. Some of them require no XML configuration at all. For my application, I simply configured the Jersey Servlet in web.xml as follows:

<servlet>
	<servlet-name>Jersey</servlet-name>
	<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
	<init-param>
		<param-name>com.sun.jersey.config.property.packages</param-name>
		<param-value>org.coenraets</param-value>
	</init-param>
	<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
	<servlet-name>Jersey</servlet-name>
	<url-pattern>/rest/*</url-pattern>
</servlet-mapping>

NOTE: Using this type of initialization, the packages parameter defines which classes Jersey will scan for URL Paths to resolve: in this case, all the classes in org.coenraets.* packages.

Defining the REST API

Before working on the implementation, I identified that my simple application would require three services:

1. Find all employees
2. Find an employee by id
3. Find a list of direct reports for a specific employee

Based on these requirements, I came up with the following REST API:

1. /api/employees
   Returns all employees
2. /api/employees/1
   Returns an employee identified by id (employee 1 in this case)
3. /api/employees/1/reports
   Returns direct reports of an employee (employee 1 in this case)

Implementing the API

Once my API was defined, providing the implementation using JAX-RS was easy. I just created a Java class defined as follows:

package org.coenraets.directory;

import java.util.List;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.PathParam;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;

@Path("/employees")
public class EmployeeResource {

	EmployeeDAO dao = new EmployeeDAO();

	@GET
	@Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
	public List<Employee> findAll() {
		return dao.findAll();
	}

	@GET @Path("{id}")
	@Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
	public Employee findById(@PathParam("id") String id) {
		return dao.findById(Integer.parseInt(id));
	}

	@GET @Path("{id}/reports")
	@Produces({ MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML })
	public List<Employee> findByManager(@PathParam("id") String managerId) {
		return dao.findByManager(Integer.parseInt(managerId));
	}
}

You annotate your class and methods with the path (@Path) and the content type (@Produces) they respond to. The serialization from model objects to the content type requested by the client happens automatically. In this application, the methods will return either JSON or XML depending on the content type requested by the client.

The approach you use to actually retrieve the data is, of course, totally up to you. In this example, I use a simple DAO, but you can of course use your own data access solution.

This application only required GET methods, but JAX-RS allows you to handle the other HTTP methods (@GET, @PUT, @POST, @DELETE and @HEAD).

Note that the package name matches the packages parameter defined in web.xml.

Testing the API

If you want to test your API before using it in a client application, you can invoke your REST services straight from a browser address bar. For example, try:

http://coenraets.org/rest/employees
http://coenraets.org/rest/employees//1
http://coenraets.org/rest/employees/1/reports

However, that doesn’t give you full control to test all the content types your API can return. A common option to test the different content types supported by your API is to use cURL and specify the content type requested in the Accept header:

curl -I http://coenraets.org/rest/employees -H’Accept:application/json’

Download the Source Code

Click here to download the source code (Eclipse Dynamic Web Project).

In my next post, I’ll share the client-side of the application: how to invoke these services using jQuery (and JSON).

Follow @ccoenraets

Flex is a powerful application framework for building first-class mobile applications for iOS, Android, and the BlackBerry PlayBook using a single programming model, a single tool, and a single code base.

If you are a Java developer, the Flex programming model is also easy to master because it is syntactically very close to Java. The Flex IDE (Flash Builder) is a plugin on top of Eclipse, which means that you can write, debug, and profile your client and server code in the same development environment.

You can also easily integrate Flex applications with a Java back end using the Remoting and Messaging services provided by BlazeDS (open source) or LCDS (commercial license). For Spring developers, the integration is even easier and more powerful using the Spring/BlazeDS integration project, which makes the Flex and Spring combination the best way to build cross-platform iOS, Android, and PlayBook applications with a Java back end.

I put together a new “Flex / Spring Mobile Test Drive” to help developers get started building these applications. The Test Drive consists of a web application with BlazeDS and the “Spring/BlazeDS integration” preconfigured and ready to use. It also includes two sample mobile applications running “out-of-the-box”: An Employee Directory and a Trader Desktop. The Employee directory demonstrates how to use Remoting to access Spring services. The Mobile Trader focuses on the Messaging integration: It shows a Spring component pushing real-time market data updates to a Flex applications.

The project is hosted on GitHub: https://github.com/ccoenraets/flex-spring-mobile-testdrive

Installation

1. Deploy flex-spring-mobile.war to your app server.
2. Import the projects into Flash Builder: (If you don’t have Flash Builder, you can download it here)
   • File > Import > General > Existing Projects into Workspace
   • Select ccoenraets-flex-spring-mobile-testdrive as the Root directory
   • Select all the projects (EmployeeDirectoryJ, flex-spring-mobile, and MobileTraderJ)
   • Click Finish
3. Running the EmployeeDirectory
   • Open config.xml in the src folder and modify the endpoint to match the hostname and port number of your app server
   • Right-click EmployeeDirectoryJ and select Run As > Mobile Application
   • Select a target platform (iOS, Android, or BlackBerry Tablet OS), select On desktop as the launch method and select a device to simulate
   • Click Run
4. Running the MobileTrader Application
   • Right-click MobileTraderJ and select Run As > Mobile Application
   • Select a target platform (iOS, Android, or BlackBerry Tablet OS), select On desktop as the launch method and select a device to simulate
   • Click Run
   • The Settings view is automatically activated the first time you run the application. Enter the MessageBroker base URL, for example: http://localhost:8080/flex-spring-mobile/messagebroker (modify the endpoint to match the hostname and port number of your app server), select a Channel type, click Save Settings, and click Start Server Feed.
   • Access the Watch tab: The list should be automatically updated with the (simulated) real time updates pushed from the Spring web app.

Follow @ccoenraets

Watch the video below to get familiar with the Test Drive environment and the sample application:

Installation Instructions

1. Download flex-java-testdrive.zip, and unzip the file in your root directory.
2. Open a Command Window or Shell, navigate to /flex-java-testdrive/tomcat/bin, and start Tomcat (for instance: catalina run).
3. Open a browser and access http://localhost:8400/testdrive/InSync/InSync.html.

Importing the projects in Flash Builder 4

1. In Flash Builder 4, click File > Import > General > Existing Projects into Workspace.
2. Specify flex-java-testdrive/projects as the root directory and click finish.
3. Explore the projects: InSync is the Flex project and java-testdrive is the Java project for the server-side classes.

In the InSync project, the classes in the services and valueObjects packages have been generated automatically by Flash Builder 4. My next blog post will show you how to generate these classes based on existing Java services deployed in BlazeDS.

NOTE: Because BlazeDS 4 hasn’t yet been released, this version of the Test Drive uses a nightly build of BlazeDS 4.

Follow @ccoenraets

Greg Wilson and Damien Mandrioli are also blogging about the new Tour de Flex real time dashboard today. Greg is the inspiration behind everything “Tour de Flex”, including the idea of the dashboard. He has the story behind the genesis of this project on his blog. Damien (from IBM/ILOG) did a fantastic job at building the client-side of the dashboard using the very cool ILOG Elixir components, and he walks you through the details on his blog.

My contribution to the project is the “real-time messaging” infrastructure. I provide the details below.

First the overall workflow…

The reason we are combining PHP and Java in this workflow is mostly historical. In the initial version of Tour de Flex, there was no Java involved: Greg was persisting loaded samples data (sample id and timestamp) directly from his PHP page. We later added LiveCycle Data Services to the picture to support the data push requirement of the dashboard, and we took the opportunity to move some code (such as the database persistence) from PHP to Java. Note that we are using LCDS for the performance and scalability of its high-end channels, but the application could also be deployed on BlazeDS.

A more straightforward architecture would be for the client to communicate directly with LCDS. For example, the client could invoke a remote object that would directly publish the loaded sample data (sample id and geolocation of the client) to the message destination. Alternatively, the client could use a Producer object to directly publish the message to the destination. Because some logic (such as geolocating the IP address and persisting the data) has to be executed at the server-side before routing the messages to the subscribed clients, you would have to write a custom message adapter if you used this approach.

We will probably streamline the workflow with one of these two approaches in the future, but in the meantime here is the source code for the servlet (logging and non-essential code removed for brevity):

package com.adobe.tdf;

import java.io.IOException;
import java.io.PrintWriter;
import java.util.Date;

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.maxmind.geoip.Location;
import com.maxmind.geoip.LookupService;

import flex.messaging.MessageBroker;
import flex.messaging.messages.AsyncMessage;
import flex.messaging.util.UUIDUtils;

public class TDFServlet extends HttpServlet {

	// Unique clientID for the message service
	private String clientID = UUIDUtils.createUUID();

	// The geocoding service
	protected LookupService lookupService;

	// A DAO to store sample requests in a database
	protected SampleRequestDAO dao = new SampleRequestDAO();

	// The LCDS message broker
	protected MessageBroker messageBroker;

	// The LCDS messaging destination where real time sample requests information is pushed
	protected String destination;

	public void init() throws ServletException {

		ServletConfig config = getServletConfig();
		destination = config.getInitParameter("messaging.destination.name");
		String path = config.getInitParameter("geocoding.database.path");
		try {
			// Load the geocoding database in init() to make sure we load it only once
			lookupService = new LookupService(path, LookupService.GEOIP_MEMORY_CACHE);
		} catch (IOException e) {
			// We swallow the exception here. If the database is not available, the feed
			// will still work but won't provide the location info.
		}
	}

	protected void doGet(HttpServletRequest request, HttpServletResponse response)
			throws ServletException, IOException {

		if (messageBroker == null)
		{
			messageBroker = MessageBroker.getMessageBroker(null);
		}

		SampleRequest sampleRequest = new SampleRequest();

		try {
			sampleRequest.setSampleId(Integer.parseInt(request.getParameter("sampleId")));
		} catch (Exception e) {
			String message = "A valid sampleId is required to process this request";
			throw new RuntimeException(message);
		}

		sampleRequest.setTimestamp(new Date());

		String ipAddress = request.getParameter("ipAddress");

		// Geolocate the IP address and add the info to the message
		if (lookupService != null && ipAddress != null)
		{
	                Location location = lookupService.getLocation(ipAddress);
			if (location != null)
			{
				sampleRequest.setLatitude(location.latitude);
				sampleRequest.setLongitude(location.longitude);
				sampleRequest.setCountry(location.countryCode);
				sampleRequest.setCity(location.city);
			}
		}

		try {
			dao.create(sampleRequest, ipAddress);
		} catch (RuntimeException e) {

		}

		String subtopic = request.getParameter("subtopic");
		if (subtopic == null) subtopic = "flex";

		// Publish the message to specified destination and subtopic.
		AsyncMessage msg = new AsyncMessage();
		msg.setDestination(destination);
		msg.setHeader("DSSubtopic", subtopic);
		msg.setClientId(clientID);
		msg.setMessageId(UUIDUtils.createUUID());
		msg.setTimestamp(System.currentTimeMillis());
		msg.setBody(sampleRequest);
		messageBroker.routeMessageToService(msg, null);

		PrintWriter out = response.getWriter();
	        out.println("<html><body>ok</body></html>");

	}

}

The servlet is responsible for three things:

1. Geolocate the IP address of the client requesting the sample. We currently use the MaxMind Geolocation API. The API is straightforward and the results seem pretty accurate.
2. Save the information about the loaded sample in a database. We keep track of historical data to be able to support future data visualization projects.
3. Publish the data about the loaded sample to a message destination. The servlet uses the Message Service Java API to directly push messages to the Flex destination (lines 97 to 104). Note that the same API exists for ColdFusion, so CF developers could use a CF page instead of this servlet to push messages to the client.

Channels

The messaging destination is set up to support different communication channels: RTMP, long polling, and regular polling. The client-side developer can decide which channel to use to communicate with the server. For example, if you wanted to use RTMP as the primary channel, fall back to long polling if the RTMP connection fails, and fall back to regular polling if the long polling connection fails you could set up your client-side ChannelSet as follows:

<mx:ChannelSet id="channelSet">
	<mx:RTMPChannel id="rtmp" url="rtmp://hostname:2037"/>
	<mx:AMFChannel url="http://hostname/context/messagebroker/amflongpolling"/>
	<mx:AMFChannel url="http://hostname/context/messagebroker/amfpolling"/>
</mx:ChannelSet>

Follow @ccoenraets

• The Test Drive now includes an annotation-based configuration sample (the Company Manager sample). Spring annotations such as @Service, @RemotingDestination, @Autowired, @RemotingInclude, and @RemotingExclude make it really easy to configure your beans and make them available through Remoting. As an example, here is the source code for the CompanyDAO class:

  package flex.spring.samples.company;
  
  import java.sql.ResultSet;
  import java.sql.SQLException;
  import java.util.HashMap;
  import java.util.List;
  import java.util.Map;
  
  import javax.sql.DataSource;
  
  import org.springframework.flex.remoting.RemotingDestination;
  import org.springframework.flex.remoting.RemotingExclude;
  import org.springframework.flex.remoting.RemotingInclude;
  import org.springframework.beans.factory.annotation.Autowired;
  import org.springframework.stereotype.Service;
  import org.springframework.jdbc.core.simple.ParameterizedRowMapper;
  import org.springframework.jdbc.core.simple.SimpleJdbcInsert;
  import org.springframework.jdbc.core.simple.SimpleJdbcTemplate;
  
  import flex.spring.samples.industry.IIndustryDAO;
  
  @Service("companyService")
  @RemotingDestination(channels={"my-amf"})
  public class CompanyDAO implements ICompanyDAO {
  
  	private final SimpleJdbcTemplate template;
  	private final SimpleJdbcInsert insertCompany;
  
  	private IIndustryDAO industryDAO;
  
  	private final ParameterizedRowMapper<Company> rowMapper = new ParameterizedRowMapper<Company>(){
  		public Company mapRow(ResultSet rs, int rowNum) throws SQLException {
  			Company company = new Company();
  			company.setId(rs.getInt("id"));
  			company.setName(rs.getString("name"));
  			company.setAddress(rs.getString("address"));
  			company.setCity(rs.getString("city"));
  			company.setState(rs.getString("state"));
  			company.setZip(rs.getString("zip"));
  			company.setPhone(rs.getString("phone"));
  			company.setIndustry(industryDAO.findById(rs.getInt("industry_id")));
  			return company;
  		}
  	};
  
  	@Autowired
  	public CompanyDAO(DataSource dataSource, IIndustryDAO industryDAO) {
  		template = new SimpleJdbcTemplate(dataSource);
  		insertCompany = new SimpleJdbcInsert(dataSource).withTableName("COMPANY").usingGeneratedKeyColumns("ID");
  		this.industryDAO = industryDAO;
  	}
  
  	@RemotingInclude
  	public Company findById(int id) {
  		return template.queryForObject("SELECT * FROM company WHERE id=?", rowMapper, id);
  	}
  
  	@RemotingInclude
  	public List<Company> findAll() {
  		return template.query("SELECT * FROM company ORDER BY name", rowMapper);
  	}
  
  	@RemotingInclude
  	public List<Company> findByName(String name) {
  		return template.query("SELECT * FROM company WHERE UPPER(name) LIKE ? ORDER BY name",
  				rowMapper,
  				"%" + name.toUpperCase() + "%");
  	}
  
  	@RemotingInclude
  	public Company create(Company company) {
  		Map<String, Object> parameters = new HashMap<String, Object>();
          parameters.put("name", company.getName());
          parameters.put("address", company.getAddress());
          parameters.put("city", company.getCity());
          parameters.put("state", company.getState());
          parameters.put("zip", company.getZip());
          parameters.put("phone", company.getPhone());
          parameters.put("industry_id", company.getIndustry().getId());
          Number id = insertCompany.executeAndReturnKey(parameters);
  		company.setId(id.intValue());
  		return company;
  	}
  
  	@RemotingInclude
  	public boolean update(Company company) {
          int count = template.update("UPDATE company SET name=?, address=?, city=?, state=?, zip=?, phone=?, industry_id=? WHERE id=?",
  				company.getName(),
  				company.getAddress(),
  				company.getCity(),
  				company.getState(),
  				company.getZip(),
  				company.getPhone(),
  				company.getIndustry().getId(),
  				company.getId());
  		return (count == 1);
  	}
  
  	@RemotingExclude
  	public boolean remove(Company company) {
  		int count = template.update("DELETE FROM company WHERE id=?", company.getId());
  		return (count == 1);
  	}
  
  }
  

• The Test Drive is now using the M3 build of Spring 3 (as opposed to M2 in the previous builds of the Test Drive).
• I modified the configuration of the long polling channel to support more persistent connections per domain based on the browser capabilities.
• And of course compared to the M2 build, this version of the Test Drive includes a number of Messaging samples.

  Using the Messaging integration, setting up a destination can be as easy as:

  <flex:message-destination id="chat" />
  

  And here is how you configure a destination mapped to a JMS topic:

  <flex:jms-message-destination id="jms-chat" jms-destination="chatTopic" />
  

Installation Instructions:

1. Download the Spring / Flex TestDrive here: http://coenraets.org/downloads/spring-flex-testdrive-RC1v2.zip
2. Unzip it in your root directory
3. Navigate to /spring-flex-testdrive/tomcat/bin and start Tomcat (for instance: catalina run)
4. Open a browser and access http://localhost:8080
5. Follow the instructions

Follow @ccoenraets

I will be joined by Mark Fisher from SpringSource and we will talk about Flex, Spring, BlazeDS and the integration of these technologies. Spring BlazeDS integration RC1 was released last week. One of the key features in RC1 is the integration of the Message service, and Mark is the lead developer on that feature.

I hope to see you there if you live in the greater Boston area.

Thu, May 14 6:00pm
Sun Microsystems – 1 Network Way, Burlington, MA
NEJUG Link

Follow @ccoenraets

SpringSource just released the RC1 build for the Spring / BlazeDS integration project. The key new feature in RC1 is the integration of the BlazeDS Message Service.

I updated my Spring BlazeDS Integration Test Drive to showcase the messaging integration.

In addition to Remoting and Security samples, the Test Drive now includes the following Messaging samples:

• Chat: Messaging basics
• Simple Data Push: A simple data push example
• Traderdesktop: A more sophisticated data push example showing how to use subtopics
• JMS Chat: A chat application using a JMS topic and exchanging messages with a Swing-based client
• Collaboration: An example showing how to use messaging to remotely drive another client’s application

Installation Instructions:

1. Download the Spring / Flex TestDrive here: http://coenraets.org/downloads/spring-flex-testdrive-RC1.zip
2. Unzip it in your root directory
3. Navigate to /spring-flex-testdrive/tomcat/bin and start Tomcat (for instance: catalina run)
4. Open a browser and access http://localhost:8080
5. Follow the instructions

As always, I’d love to hear your feedback and your ideas to improve this Test Drive.

I will probably have another version next week with a couple of additional samples and more documentation for the Message Service, but I already wanted to make this version available to allow you to experiment RC1 samples.

Christophe

Follow @ccoenraets