Spring Integration - Spring Enterprise Recipes: A Problem Solution Approach - page 316

with the JMS Message interface, although they have some similarities. Had you not specified the
extract-payload option, the type of payload on the Spring Integration Message interface would have
been javax.jms.Message . The onus of extracting the payload would have been on you, the developer,
but sometimes getting access to that information is useful. Rewritten to handle unwrapping the
javax.jms.Message , the example would look a little different:

package com.apress.springenterpriserecipes.springintegration;

import org.apache.log4j.Logger;
import org.springframework.integration.annotation.ServiceActivator;
import org.springframework.integration.core.Message;
import java.util.Map;

public class InboundHelloWorldJMSMessageProcessor {
private static final Logger logger =
Logger.getLogger(InboundHelloWorldJMSMessageProcessor.class);

@ServiceActivator
public void handleIncomingJmsMessageWithPayloadNotExtracted(
Message<javax.jms.Message> msgWithJmsMessageAsPayload
) throws Throwable {
javax.jms.MapMessage jmsMessage = (MapMessage)

➥

msgWithJmsMessageAsPayload.getPayload();
logger.debug(String.format("firstName: %s, lastName: %s, id:%s", ➥

jmsMessage.getString("firstName"),
jmsMessage.getString("lastName"), jmsMessage.getLong("id")));
}
}

You could have specified the payload type as the type of the parameter passed into the method.
If the payload of the message coming from JMS was of type Cat , for example, the method prototype
could just as well have been public void handleIncomingJmsMessage( Cat inboundJmsMessage) throws
Throwable . Spring Integration will figure out the right thing to do. In this case, I prefer access to the
Spring Integration Message , which has header values and so on that can be useful to interrogate.
Also note that you don't need to specify throws Throwable . Error handling can be as generic or as
specific as you want in Spring Integration.
In the example, you use the @ServiceActivator to invoke the functionality where the integration
ends. However, you can forward the response from the activation on to the next channel by returning a
value from the method. The type of the return value, be it a typed Message or a simple POJO, will be sent
directly or wrapped in a Message and then sent out on the output channel configured on the service-
activator . You can change the payload of the input Message for the Message on the outbound channel.
Thus, a service-activator is a very flexible component in which to put hooks to your system and to help
mold the integration.
This solution is pretty straightforward, and in terms of configuration for one JMS queue, it's not
really a win over straight MDPs because there's an extra level of indirection to overcome. The Spring
Integration facilities make building complex integrations easier than Spring Core or EJB3 could because
the configuration is centralized. You have a birds-eye view of the entire integration, with routing and
processing centralized, so you can better reposition the components in your integration. However, as
you'll see, Spring Integration wasn't meant to compete with EJB and Spring Core; it shines at solutions
that couldn't naturally be built using EJB3 or Spring Core.