Yes - what I had to do was put the error-channel="failFOMessageChannel" right at the start of the message flow then it picked up on it.
<int:gateway id="foGateway" service-interface="com.xxxx.mercury.fo.FOGateway"
Well, this is a bit different.
You are using Gateway. Messaging Gateway is unique in the way that it actually by definition is bi-directional which means it expectes a reply (although we do allow void gateway methods, but that is a different topic). The fact that a typical gateway expects a reply means that it encapsulates both the producer and consumer in a single component. This means that while it sends Message to a default-request-channel it (the consumer part of it) actually waits for the reply from the reply channel which could be explicit or implicit. This contract must be preserved regardless if the downstream flow resulted in exception or if it was sync or async. So there is always an implicit error-channel when constructing gateway and all errors will be sent to that channel (it is anonymous temporary channel). Once the error message is received it wil be converted to a MessagingException and re-thrown. However, some times you don't want that and as I explained in the previous post you may want to always return successfully while communicating the error (e.g., SOAP Fault is a good example). In this case you can define an explicit error-channel (as you did) and what that does is allowing the ErrorMessage received on the anonymous errorChannel to be delegated to an explicit error-channel where user can subscribe to and handle the error. Handling could be done in two ways. 1. Receive ErrorMessage, process it (e.g., log) and return a new Successful message with some error code in the payload or simply re-throw an exception or different exception after processing original error etc...
Does that clarify?
Can I ask the question again - as it helps me to understand. If I have a gateway and a chain of other processes, I want those downstream processes to be able to throw an exception - then have the gateway receive the error - and keep the request/reply contract.
You say that the contract (to receive a reply) must be preserved regardless of a downstream exception - does this mean that a reply message must be sent down the receive-channel even if an exception has happened. My instinct is to think of Java method semantics ... and to say the reply message could be received down the reply-channel (like a return value in a method) *or* the error-channel (like an exception in a method).
So just to clarify (again) - if a down stream process throws an exception could I send that exception (indirectly) to the reply channel - and meet the contract that way?
When inbound gateway is created framework automatically creates two more anonymous and temporary channels (replyChannel and errorChannel). Actually its one channel which is used for errors and replies and then the reference to this channel travels with Message headers (replyChannel, errorChannel)
This happens regardless if you explicitly define reply-channel and/or error-channel.
When exception happens downstream it will be converted to an ErrorMessage and sent to the 'errorChannel' provided via 'errorChannel' header. Once the ErrorMessage is received two things may happen. If you did not define an explicit error-channel, then the payload of the ErrorMessage will be extracted (Throwable) and re-thrown back to the caller. If you DID define an explicit error-channel, then the ErrorMessage will be sent to that channel. Now the subscriber of that channel has two choices. 1. Handle exception and return successful Message or 2. Handle exception and return it so it could be re-thrown back to the caller.
So basically the error-channel on the gateway gives you one last chance to deal with the exception before such exception has been communicated back to the caller.
I am using Spring Integration in my project.
Below is the part of the configuration that i am using in my project whenever there is an exception in the header enricher it is not propogated to the error channel
Kindly throw some light on this
<header name="Information" method="extractInformation" ref="infoExtractor" />
<beans:property name="description" value="Error in info extractor" />
Please do not double-post on this forum. I even replied to your first message already.