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