diff --git a/spring-integration-reference/images/message-bus.png b/spring-integration-reference/images/message-bus.png index 40186c2cd2..f7b72f5943 100644 Binary files a/spring-integration-reference/images/message-bus.png and b/spring-integration-reference/images/message-bus.png differ diff --git a/spring-integration-reference/src/configuration.xml b/spring-integration-reference/src/configuration.xml index 495845d42a..d5ea859aba 100644 --- a/spring-integration-reference/src/configuration.xml +++ b/spring-integration-reference/src/configuration.xml @@ -403,7 +403,7 @@ is a File source with an endpoint whose polling will be scheduled to execute every 30 seconds by the MessageBus. - + @@ -411,11 +411,16 @@ Likewise, here is an example of a JMS target that is registered within a 'channel-adapter' and whose Messages will be received from the "exampleChannel" that is polled every 500 milliseconds. - + -]]> +]]> + + + Any Channel Adapter can be created without a "channel" reference in which case it will implicitly create an + instance of DirectChannel. The created channel's name will match the "id" attribute + of the <channel-adapter/> element. Therefore, if the "channel" is not provided, the "id" is required. @@ -446,58 +451,57 @@ public class FooService { } } + + The @MessageEndpoint is not required. If you want to configure a POJO reference from the "ref" attribute + of a <service-activator/> element, it is sufficient to provide the @Handler method annotation. As long + as the "annotation-driven" support is enabled, a Spring-managed object with that method annotation (or the + others which are described below) will be post-processed such that it can be used as a reference from an + XML-configured endpoint. + In most cases, the annotated handler method should not require the Message type as its parameter. Instead, the method parameter type can match the message's payload type. - @MessageEndpoint(input="fooChannel") -public class FooService { + public class FooService { @Handler public void bar(Foo foo) { ... } + } When the method parameter should be mapped from a value in the MessageHeader, another - option is to use the @HeaderAttribute and/or - @HeaderProperty parameter annotations. + option is to use the parameter-level @Header annotation. @MessageEndpoint(input="fooChannel") public class FooService { @Handler - public void bar(@HeaderAttribute("fooAttrib") Foo foo) { + public void bar(@Header("foo") Foo foo) { ... } -} - @MessageEndpoint(input="fooChannel") -public class FooService { - @Handler - public void bar(@HeaderProperty("foo") String input) { - ... - } } As described in the previous section, when the handler 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 that - the the endpoint's output channel will be used if available, and the message header's 'returnAddress' value will be + the the endpoint's output channel will be used if available, and the message header's RETURN_ADDRESS value will be the fallback. To configure the output channel for an annotation-driven endpoint, provide the 'output' attribute on the @MessageEndpoint. @MessageEndpoint(input="exampleChannel", output="replyChannel") - Just as the 'schedule' sub-element and its 'period' attribute can be provided for a namespace-based - endpoint, the @Polled annotation can be provided with the + Just as the 'poller' sub-element and its 'period' attribute can be provided for a namespace-based + endpoint, the @Poller annotation can be provided with the @MessageEndpoint annotation. @MessageEndpoint(input="exampleChannel") -@Polled(period=3000) +@Poller(period=3000) public class FooService { ... } Likewise, @Concurrency provides an annotation-based equivalent of the - <concurrency/> element: + <pool-executor/> element: @MessageEndpoint(input="fooChannel") @Concurrency(coreSize=5, maxSize=20) public class FooService { @@ -506,13 +510,19 @@ public class FooService { public void bar(Foo foo) { ... } + } - Two additional annotations are supported, and both act as a special form of handler method: - @Router and @Splitter. As with the - @Handler annotation, methods annotated with either of these two annotations can - either accept the Message itself or the message payload type as the parameter. + Several additional annotations are supported, and three of these act as a special form of handler method: + @Router, @Splitter and + @Aggregator. As with the @Handler annotation, + methods annotated with these annotations can either accept the Message itself, the + message payload, or a header value (with @Header) as the parameter. In fact, the method can accept a combination, + such as: + someMethod(String payload, @Header("x") int valueX, @Header("y") int valueY); + + When using the @Router annotation, the annotated method can return either the MessageChannel or String type. In the case of the latter, the endpoint will resolve the channel name as it does for the default output. Additionally, the method can return @@ -534,12 +544,9 @@ public List<String> route(Foo payload) {...} In addition to payload-based routing, a common requirement is to route based on metadata available within the message header as either a property or attribute. Rather than requiring use of the Message type as the method parameter, the @Router - annotation may also use the same parameter annotations that were introduced above. + annotation may also use the same @Header parameter annotation that was introduced above. @Router -public String route(@HeaderProperty("customerType") String customerType) - -@Router -public List<String> route(@HeaderAttribute("orderStatus") OrderStatus status) +public List<String> route(@Header("orderStatus") OrderStatus status) The @Splitter annotation is also applicable to methods that expect either the @@ -553,22 +560,33 @@ List<LineItem> extractItems(Order order) { } - The @Publisher annotation is convenient for sending messages with AOP - after-returning advice. For example, each time the following method is invoked, its return - value will be sent to the "fooChannel": + The @Aggregator annotation may be used on a method that accepts a collection + of Messages or Message payload types and whose return value is a single Message or single Object that will + be used as the payload of a Message. + aggregateMessages(List> messages) { ... } + +@Aggregator +public Order aggregateOrder(List items) { ... }]]> + + + Finally, the @Publisher is an annotation that triggers the creation of a Spring + AOP Proxy such that the return value, exception, or method invcation arguments can be sent to a Message Channel. + For example, each time the following method is invoked, its return value will be sent to the "fooChannel": - - - Similarly, the @Subscriber annotation triggers the retrieval of messages from a - channel, and the payload of each message will then be sent as input to an arbitrary method. This is one of the - simplest ways to configure asynchronous, event-driven behavior: - + The return value is published by default, but you can also configure the payload type: + @Publisher(channel="testChannel", payloadType=MessagePublishingInterceptor.PayloadType.ARGUMENTS) +public void publishArguments(String s, Integer n) { + ... +} + +@Publisher(channel="testChannel", payloadType=MessagePublishingInterceptor.PayloadType.EXCEPTION) +public void publishException() { + throw new RuntimeException("oops!"); +} \ No newline at end of file