Tutorial: Unmarshalling SOAP Maps with JAXB into a List of Objects with a sprinkle of Spring Integration

Back in August, I posted about invoking web services with Spring Integration using XStream marshalling/unmarshalling.  That post was based on a project I had just finished at the time.  Recently, I had to make some changes to that project in order to implement another web service offered by the same provider.  This particular web service was returning a SOAP Map like before, however instead of a simple String key and String value, I had String keys and Map values.  With XStream, this seemed to be not so simple to implement.  After a bit of looking around, I decided to try and swap out XStream for JAXB.  I could have simply added JAXB and used it strictly on the new web service, but it sounded like more fun getting JAXB working across the application with a more sophisticated implementation than what I had done with XStream.  The other thing I wanted to do was unmarshal the Map as a List of Objects because for the most part, the key itself didn’t matter too much and there was a finite list of those keys.  Here’s a sample excerpt of XML being returned by the new web service.

<item>
    <key xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">mainkey</key>
    <value xsi:type="ns1:Map">
        <item>
            <key xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">key1</key>
            <value xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">value1</value>
        </item>
        <item>
            <key xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">key2</key>
            <value xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="soapenc:string">value2</value>
        </item>
    </value>
</item>

Register your classes with the JAXB marshaller

In Spring, there’s the convenient OXM namespace for registering various types of XML marshallers.  Here’s how we register the JAXB annotated classes with the JAXB marshaller.

<oxm:jaxb2-marshaller id="jaxbMarshaller">
    <oxm:class-to-be-bound name="com.patrickgrimard.ws.Request"/>
    <oxm:class-to-be-bound name="com.patrickgrimard.ws.StringResponse"/>
    <oxm:class-to-be-bound name="com.patrickgrimard.ws.MapResponse"/>
    <oxm:class-to-be-bound name="com.patrickgrimard.util.StringDataItem"/>
    <oxm:class-to-be-bound name="com.patrickgrimard.util.ArrayDataItem"/>
</oxm:jaxb2-marshaller>

The first thing I did was start writing an API for dealing with Maps that had String values, and then adapted it to handle Map values.

Unmarshalling simple Maps of String values into a List of Objects

This starts with a simple interface I created using Java Generics called DataItem<T>.  Now if anybody’s used JAXB, they know that when unmarshalling XML with JAXB, it can’t handle interfaces, so the objects and their properties need to be concrete implementations that can be instantiated.  Here is the DataItem<T> interface.

public interface DataItem<T> {
    public String getKey();

    public void setKey(String key);

    public T getValue();

    public void setValue(T value);
}

With this interface, we can specify the type of the Map’s value property.  The first implementation of this interface will be StringDataItem.

Let’s work together!

Recently I’ve had the opportunity to collaborate on a project with someone that lives on the opposite side of the world.  In Australia to be precise.  It’s been a fun experience and it’s one I hope to repeat.  That being said, if you’re looking to hire a consultant on your current project, then don’t hesitate to contact me.

Head on over to my Developer for Hire page and take a look at my areas of expertise.

-Cheers!

String to Date Converter with Spring’s Conversion Service

Recently I was working on a Spring MVC project.  I had an @RequestMapping where one of the method’s @RequestParam arguments was a java.util.Date type.  I didn’t think much of it as I was writing the method, until when I tested the application, it threw an exception.  I quickly discovered that there’s no String to Date converter registered by default.

So in follow up to my last post where I showed you how to create a JSON collection String to List converter, I’m going to write this quick post to show you how to create a String to Date converter.

public class ApplicationConversionServiceFactoryBean extends FormattingConversionServiceFactoryBean {

	@Override
	protected void installFormatters(FormatterRegistry registry) {
		super.installFormatters(registry);
		registry.addConverter(getStringToDateConverter());
	}

	public Converter<String, Date> getStringToDateConverter() {
		return new Converter<String, Date>() {

			@Override
			public Date convert(String source) {
				SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
				try {
					return sdf.parse(source);
				} catch (ParseException e) {
					return null;
				}
			}
		};
	}
}

And that’s all there is to it.  Simply replace the SimpleDateFormat pattern with the pattern you need in your application, register the conversion service in your MVC config as mentioned in my previous post and voila!

Convert a JSON collection from String to List with Jackson using Spring’s Conversion Service

One of the nice features I’ve grown to love recently while using the Spring framework is the Spring conversion system.  Where the Spring conversion system shines in my opinion is in MVC applications.  When you create a Spring MVC application using annotation based configuration, you’ll have something like this in your servlet application context:

<mvc:annotation-driven/>

This line will register Spring’s default conversion service instance using org.springframework.format.support.FormattingConversionServiceFactoryBean which registers default converters and formatters.  This class can easily be extended to provide your own converters and formatter.  When you create a Spring MVC application using Spring Roo, this is done for you automatically.  What you end up with is something like this in your servlet application context:

<mvc:annotation-driven conversion-service="applicationConversionService"/>
<bean class="org.example.ApplicationConversionServiceFactoryBean" id="applicationConversionService"/>

What we’ve done here (or Roo if that’s what you’re using) is register a custom conversion service with id=”applicationConversionService”.  With a Roo managed project, it will manage an ITD with some converters for converting things like composite key types into JSON strings which it also encodes using Base64, which can be useful for referencing an entity ID by a composite key within your MVC application.

Let’s look at creating a custom converter for converting a JSON collection from a String into a List<Type> using Jackson.  Type being whatever type you want, be it your own or other.

public class ApplicationConversionServiceFactoryBean extends FormattingConversionServiceFactoryBean {

	private Log log = LogFactory.getLog(this.getClass());

	@Override
	protected void installFormatters(FormatterRegistry registry) {
		super.installFormatters(registry);
		registry.addConverter(getJSONCollectionToListConverter());
	}

	public Converter<String, List<MyType>> getJSONCollectionToListConverter() {
		return new Converter<String, List<MyType>>() {

			@Override
			public List<MyType> convert(String source) {
				ObjectMapper mapper = new ObjectMapper();
				List<MyType> myTypeList = null;
				try {
					myTypeList = mapper.readValue(source, new TypeReference<List<MyType>>() {});
				} catch (Exception e) {
					if(log.isErrorEnabled())
						log.error("Error converting JSON collection to List<MyType>.", e);
				}
				return myTypeList;
			}
		};
	}
}

As you can see, it’s quite simple to register your own converter.

Invoking web services with Spring Integration and XStream marshalling

Recently I had the opportunity to learn a bit about web services.  I had never worked with them before, but naturally my first thought was to use Spring Integration’s web services support because Spring Integration just makes everything so much simpler to do.

One of my main goals was keeping things as simple as possible.  That meant not having to get my hands too dirty converting objects to XML and XML to objects.  So I needed to find an XML marshalling solution that was just plain simple.  I didn’t have much experience with them in the past and I had tried DOM and SAX but found them too verbose.  So I looked at the ones that Spring Integration supported.  I finally settled on XStream because it’s annotation based configuration seemed so simple, and it was.

Before I go on, I should mention that I won’t be posting the full source of the project this tutorial is based on since it was for a client of mine.

Spring Integration configuration for starters

To begin, we’ll look at the Spring Integration configuration.  We’ll first register an XStream marshaller which will convert objects to XML and XML to objects.  Then I’ll define aliases to our objects as well as define which objects are annotated.  The aliases you define make it easier for the XStream marshaller to unmarshall XML responses into specific objects.  The alias or key is essentially the root element of the XML being unmarshalled.  Next the same classes are defined as a list for the annotated classes property.  Annotations that get added to elements of those classes assist XStream in making the XML output from marshalling look “prettier.”  More on that in the next section.

<beans:bean id="xstreamMarshaller" class="org.springframework.oxm.xstream.XStreamMarshaller">
	<beans:property name="aliases">
		<beans:props>
			<beans:prop key="request">com.example.Request</beans:prop>
			<beans:prop key="response">com.example.Response</beans:prop>
		</beans:props>
	</beans:property>
	<beans:property name="annotatedClasses">
		<beans:list>
			<beans:value>com.example.Request</beans:value>
			<beans:value>com.example.Response</beans:value>
		</beans:list>
	</beans:property>
</beans:bean>

<gateway id="requestGateway"
	default-request-channel="requestChannel"
	service-interface="com.example.RequestGateway"
	error-channel="errorChannel"/>

<chain input-channel="requestChannel">
	<ws:outbound-gateway uri="http://www.example.com/web-service"
		marshaller="xstreamMarshaller"/>
	
	<service-activator ref="responseServiceActivator"/>
</chain>

<chain input-channel="errorChannel" output-channel="mailChannel">
	<int-mail:header-enricher>
		<int-mail:subject value="${notification.subject}"/>
		<int-mail:to value="${notification.to}"/>
		<int-mail:from value="${notification.from}"/>
	</int-mail:header-enricher>
	
	<object-to-string-transformer/>
</chain>

<channel id="mailChannel"/>

<int-mail:outbound-channel-adapter channel="mailChannel" host="${smtp.server}"/>

Along with the XStream marshaller, I’ve defined a request gateway which will serve as the initial entry point for messages being sent to the web service.  The service interface is just that, a Java interface that defines what kind of message or more specific, what kind of message payload will be sent to the gateway.

public interface RequestGateway {

	public void invoke(Request request);
}

I’ve also defined a couple chains which simply encapsulate elements that share a common input channel but need to be invoked in specific order.  There’s the request channel which receives the messages from the request gateway, which is then sent off on the the <ws:outbound-gateway> element. That’s where the web service invocation actually takes place. Finally the error channel which I’ll use to send notification emails if an exception occurs.  When errors occur in downstream elements, they will flow up to the request gateway which will send them out on the error channel.

Using a different version of Dojo in a Spring Roo generated project

I haven’t yet come across a time when I actually needed to use a different version of Dojo in my own Roo generated project, but if you’re interested in knowing how to do it, follow along.  I actually saw the question asked in an old Spring forum post and decided I wanted to see for myself how it’s done.  The first thing you’ll need to do is download the version of Dojo you wish to use.  Currently the latest release is 1.6.0, so I’ve downloaded that.  If you don’t already have one, you will need a directory called “web-resources” below META-INF in the src/main/resources directory.  By default, a Roo generated app will create an <mvc:resources> element in the webmvc-config.xml file as follows:

<mvc:resources location="/, classpath:/META-INF/web-resources/" mapping="/resources/**"/>

This tells your application to serve up static content mapped with “/resources/**” to either the root of your application or the web-resources directory below META-INF on your application classpath.  The location attribute is a comma separated list of locations, so you can add more if you wish.  To keep things tidy, I’ve created a subfolder within web-resources, called “dojo-1.6.0″ in which I’ll keep the Dojo toolkit.  Here’s what things should look like at this point.

HTML Scraping with a dose of Spring Integration

If you’re reading this, chances are you’ve either tried to scrape HTML before or you’re curious how Spring Integration can help make at least part of the job much simpler.  In a perfect world, you’d have a web service you can consume in some fashion, however in the real world, you don’t always have that option.  Scraping a site’s HTML, although a bit more challenging and not always perfect, can get the job done.

In this post, I’ll show you how Spring Integration can help you with all the plumbing involved and all you have to focus on is parsing the HTML.

Suppose you have a POST request to some URL with query string parameters and/or path variables.  Spring Integration makes this very easy with an http outbound-gateway.  First let’s start with the class that will create the initial message to pass off to Spring Integration.  The payload of our message will simply be the value for a query string parameter in the URL.  Spring Integration calls these URI variables.  If you had more than one of these variables to fill, you could pass an object in your payload, you could set message headers, etc.  All you’d have to do afterwards is use the correct SpEL expression while setting the URI variables to extract the correct value.  The following class creates our Message.

@Component
public class HtmlRequester {

	private MessageChannel htmlRequestChannel;

	@Inject
	public void setHtmlRequestChannel(MessageChannel htmlRequestChannel) {
		this.htmlRequestChannel = htmlRequestChannel;
	}

	public HtmlRequester() {}

	public void requestHtml(String queryStringParameter) {
		MessagingTemplate template = new MessagingTemplate();
		Message<String> message = MessageBuilder.withPayload(queryStringParameter).build();
		template.send(htmlRequestChannel, message);
	}
}