diff --git a/spring-integration-reference/reference/src/configuration.xml b/spring-integration-reference/reference/src/configuration.xml
index e6d89e098a..98323c651c 100644
--- a/spring-integration-reference/reference/src/configuration.xml
+++ b/spring-integration-reference/reference/src/configuration.xml
@@ -105,10 +105,10 @@
to reference any Spring-managed object that implements the ChannelInterceptor
interface:
-
+ ]]>]]>]]>
- In general, it is a good idea to define the interceptors in a separate location since they usually provide
- common behavior that can be reused across multiple channels.
+ In general, it is a good idea to define the interceptor implementations in a separate location since they
+ usually provide common behavior that can be reused across multiple channels.
@@ -129,16 +129,26 @@
In either case (MessageHandler or arbitrary object/method), when the handling
method returns a non-null value, the endpoint will attempt to send the reply message to an appropriate reply
channel. To determine the reply channel, it will first check for a value in the message header's
- 'replyChannelName' property. If that value is available, it will attempt to resolve the channel by performing a
+ 'returnAddress' property. If that value is available, it will then check its type. If it is
+ a MessageChannel, the reply message will be sent to that channel. If it is a
+ String, then the endpoint will attempt to resolve the channel by performing a
lookup in the ChannelRegistry. If the message header does not contain a
- 'replyChannelName' property, then it will fallback to its own 'defaultOutputChannel' property. If neither is
- available, then a MessageHandlingException will be thrown. To configure the default
- output channel when using the XML namespace, provide the 'default-output-channel' attribute:
+ 'returnAddress' property at all, then it will fallback to its own 'defaultOutputChannelName' property. If
+ neither is available, then a MessageHandlingException will be thrown. To configure the
+ default output channel when using the XML namespace, provide the 'default-output-channel' attribute:
<endpoint input-channel="exampleChannel"
handler-ref="somePojo"
handler-method="someMethod"
default-output-channel="replyChannel"/>
+
+ Endpoint's also support MessageSelectors as described in
+ . To configure selectors with namespace support, simply add one or more
+ <selector> sub-elements to the endpoint definition:
+
+ ]]>]]>]]>
+
When the MessageBus registers the endpoint, it will activate the subscription
by assigning the endpoint to the input channel's dispatcher. The dispatcher is capable of handling multiple
diff --git a/spring-integration-reference/reference/src/core-api.xml b/spring-integration-reference/reference/src/core-api.xml
index b633f535c3..51d7e33973 100644
--- a/spring-integration-reference/reference/src/core-api.xml
+++ b/spring-integration-reference/reference/src/core-api.xml
@@ -398,4 +398,47 @@ public void registerHandler(String name, MessageHandler handler, Subscription su
single implementation: DefaultMessageEndpoint.
+
+
+ MessageSelector
+
+ As described above, when a MessageHandler is registered with the message bus, it
+ is hosted by an endpoint and thereby subscribed to a channel. Often it is necessary to provide additional
+ dynamic logic to determine what messages the handler should receive. The
+ MessageSelector strategy interface fulfills that role.
+ message);
+}]]>
+ A MessageEndpoint can be configured with zero or more selectors, and will only
+ receive messages that are accepted by each selector. Even though the interface is simple to implement, a couple
+ common selector implementations are provided. For example, the PayloadTypeSelector
+ provides similar functionality to Datatype Channels (as described in )
+ except that in this case the type-matching can be done by the endpoint rather than the channel.
+ (123)));
+assertFalse(selector.accept(new GenericMessage(someObject)));
+]]>
+ Another simple but useful MessageSelector provided out-of-the-box is the
+ UnexpiredMessageSelector. As the name suggests, it only accepts messages that have
+ not yet expired.
+
+
+ Essentially, using a selector provides reactive routing whereas the Datatype Channel
+ and Message Router provide proactive routing. However, selectors accommodate additional
+ uses. For example, the MessageChannel's 'purge' method accepts a selector:
+ channel.purge(someSelector);
+ There is even a ChannelPurger utility class whose purge operation is a good candidate for
+ Spring's JMX support:
+ ChannelPurger purger = new ChannelPurger(channel, new ExampleMessageSelector());
+purger.purge();
+
+
+ Implementations of MessageSelector might provide opportunities for reuse on
+ channels in addition to endpoints. For that reason, Spring Integration provides a simple selector-wrapping
+ ChannelInterceptor that accepts one or more selectors in its constructor.
+ MessageSelectingInterceptor interceptor = new MessageSelectingInterceptor(selector1, selector2);
+channel.addInterceptor(interceptor);
+
+
\ No newline at end of file