From 8706143b898e28c30cf8dfff5c88637846067423 Mon Sep 17 00:00:00 2001 From: ozhurakousky Date: Wed, 8 Sep 2010 01:09:59 -0400 Subject: [PATCH] INT-1426, removed references to @MessageMapping annotation --- src/docbkx/configuration.xml | 40 -------------------------------- src/docbkx/service-activator.xml | 2 +- 2 files changed, 1 insertion(+), 41 deletions(-) diff --git a/src/docbkx/configuration.xml b/src/docbkx/configuration.xml index 3748583eb8..9b166d732d 100644 --- a/src/docbkx/configuration.xml +++ b/src/docbkx/configuration.xml @@ -250,46 +250,6 @@ public class FooService { } } - -A more powerful and flexible way to map Messages to method arguments is to use @MessageMapping -annotation which allows you to define expression via Spring 3.0 Expression Language support to help parse -the message payload and/or header and map the parsed values to method arguments. - -For example: - -public void fromMessageToMethod(@MessageMapping("headers.day") String argA, - @MessageMapping("#this") Message message, - @MessageMapping("payload") Employee payloadArg, - @MessageMapping("payload.fname") String value, - @MessageMapping("headers") Map headers) { ... } - -As you can see, the above method takes 5 arguments where: - - - First - will be mapped to the value of 'day' header - - - Second - will be mapped to the Message itself - - - Third - will be mapped to the Payload - - - Fourth - will be mapped to the 'fname' property of a Payload object - - - Fifth - will be mapped to MessageHeaders - - - - - A Map-typed argument does not strictly require the use of the @Headers annotation. In other words - the following is also valid: public void bar(String payload, Map<String, Object> headerMap) - However this can lead to unresolvable ambiguities if the payload is itself a Map. For that reason, we - highly recommend using the annotation whenever expecting the headers. For a much more detailed - description, see the javadoc for MethodParameterMessageMapper. - - For several of these annotations, when a Message-handling method returns a non-null value, the endpoint will attempt to send a reply. This is consistent across both configuration options (namespace and annotations) in diff --git a/src/docbkx/service-activator.xml b/src/docbkx/service-activator.xml index 1d624f3010..3aad8fc2e5 100644 --- a/src/docbkx/service-activator.xml +++ b/src/docbkx/service-activator.xml @@ -44,7 +44,7 @@ The argument in the service method could be either a Message or an arbitrary type. If the latter, then it will be assumed that it is a Message payload, which will be extracted from the message and injected into such service method. This is generally the recommended approach as it follows and promotes a POJO model when working with Spring - Integration. Arguments may also have @Header, @Headers or @MessageMapping annotations as described in + Integration. Arguments may also have @Header, @Headers annotations as described in Since v1.0.3 of Spring Integration, the service method is not required to have an argument at all, which means you