diff --git a/spring-integration-reference/src/chain.xml b/spring-integration-reference/src/chain.xml index 25c9b7efb6..2564a9c7e0 100644 --- a/spring-integration-reference/src/chain.xml +++ b/spring-integration-reference/src/chain.xml @@ -70,6 +70,46 @@ values. You could obtain the same result by implementing a MessageHandler that did the header modifications and wiring that as a bean. + + + Some time you need to make a nested call to another chain from within the chain and then come + back and continue execution within the original chain. + To accomplish this you can utilize Messaging Gateway by including light-configuration via <gateway> element. + For example: + + + + + + + +   + + + + + +   + + + + + + + + + + + + ]]> + +In the above example the nested-chain-a will be called at the end of main-chain processing by the 'gateway' element +configured there. While in nested-chain-a a call to a nested-chain-b will be made after header enrichment and then it will +come back to finish execution in nested-chain-b finally getting back to the main-chain. +When light version of <gateway> element is defined in the chain SI will construct an instance SimpleMessagingGateway + (no need to provide 'service-interface' configuration) which will take the message in its current state and will place it on the channel defined via 'request-channel' attribute. + Upon processing Message will be returned to the gateway and continue its journey within the current chain. + \ No newline at end of file diff --git a/spring-integration-reference/src/channel.xml b/spring-integration-reference/src/channel.xml index 6dedc9cd0c..0e46803ab7 100644 --- a/spring-integration-reference/src/channel.xml +++ b/spring-integration-reference/src/channel.xml @@ -523,6 +523,40 @@ public Message receive(final PollableChannel channel) { ... }]]> + +
+ Global Channel Interceptor Configuration + + Channel Interceptors allow you for a clean and concise way of applying cross-cutting behavior per individual channel. + But what if the same behavior should be applied on multiple channels, configuring the same set of interceptors for + each channel would not be the most efficient way. The better way would be to configure interceptors globally and apply + them on multiple channels in one shot. Spring Integration provides capabilities to configure Global Interceptor Chains + and apply them on multiple channels. + Look at the example below: + + + +]]> + <channel-interceptor-chain> element will assemble the chain of interceptors and will apply them on all the + channels defined in the <channel-name-patter> attribute. In the above case the two interceptors that are defined + within the chain are going to be applied on 'foo' channel and all other channels that begin with 'bar' and 'input'. + The <order> attribute allows you to manage the place where this interceptor chain will be injected. + For example, channel 'inputChannel' could have individual interceptors configured locally (see below): +   + +   + +]]> + The reasonable question would be where interceptors defined by channel-interceptor-cahin should be injected + in relation to the existing one(s) (configured locally or through other global chains)? Current implementation provides + a very simple and clever mechanism of handling this. Positive number in the order attribute will ensure interceptor injection + after existing interceptors and negative number will ensure that such interceptors injected before. + This means that in the above example interceptors configured in global interceptor chain would be injected after + 'wire-tap' interceptor configured locally. If there was another global chain with matching channel-name-pattern the + order between the interceptors defined in two chains would be determined based on who's got the higher or lower + value in order attribute. + +
Wire Tap