From 8a6c4babee1ebd1ebd10e73da92e998f5ca6f92a Mon Sep 17 00:00:00 2001 From: Mark Fisher Date: Thu, 28 Feb 2008 00:12:52 +0000 Subject: [PATCH] Updating reference documentation for M2. --- .../reference/src/configuration.xml | 24 ++++++++--- .../reference/src/core-api.xml | 43 +++++++++++++++++++ 2 files changed, 60 insertions(+), 7 deletions(-) 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