Why no error-channel attribute for int-http:outbound-gateway?

[squawk]

My int-http:outbound-gateway calls out to a server that may return an error message with a HTTP 500 status code.

If that's the case I want to do a small amount of error handling only, I don't want the message to go onto the reply-channel.

I set the error-handler and it detects and processes this scenario, but for some reason the message still gets placed on the reply-channel.

So, I'm wondering if there's a reason why there isn't support for a error-channel, or if there's some way of stopping certain (e.g. 500) messages going to the reply-channel?

Thanks

[Gary Russell]

The error-channel goes on the inbound endpoint; when a downstream component throws an exception, an ErrorMessage is sent to that error channel. The ErrorMessage payload has two properties cause (the exception) and failedMessage.

You then handle the error on that channel.

[squawk]

Thanks, I put the error-channel on the inbound endpoint and now pick up the ErrorMessage in a transformer on the error channel.

When the external server returns a HTTP 500 message, some additional information about the failure is passed in a HTTP header field. I had hoped to pick up this header in my transformer, but it doesn't look like HTTP headers are mapped on to ErrorMessage. Is there any way to retrieve the HTTP headers from ErrorMessage / error channel?

[Mark Fisher]

You can access the original Message via the ErrorMessage payload's "failedMessage" property.

[squawk]

Thanks, but it's not the original message headers that I want.

The original message is passed to an outbound http gateway. The gateway makes a HTTP request and gets a 500 response. It is the HTTP headers of this 500 response that I'd like to be able to access from the ErrorMessage.

[Mark Fisher]

Have you considered adding a router after the HTTP outbound gateway instead? You could route based on the status code in the reply Message's header.

[squawk]

I'd be happy to do that, but from what I've seen the 500 response causes a MessageHandlingException inside the gateway which results in an ErrorMessage that would bypass the router? Or should I also override the error-handler so a 500 response isn't treated as an error?

[Mark Fisher]

Right, the DefaultResponseErrorHandler on the underlying RestTemplate will automatically throw an Exception for any error status. So, yes, you could provide one that subclasses the default and bypasses that logic for certain status codes. Then that HTTP response would be sent downstream (via the gateway's "reply-channel") as if it were a "normal" reply Message.

[squawk]

Ah, I've run into a problem with that method: although i now get the http header ok, i also need the contents of the original message (previously, using ErrorMessage, I could retrieve these using getFailedMessage). Is there any way of retrieving the original message contents given the reply message?

[Mark Fisher]

Well, you could add a header-enricher upstream from the gateway that stores the original payload (or relative part(s) of it that you need in the error flow case) in a header. However, at the risk of going back and forth again, if you do use the error-channel approach, the actual Exception thrown by the DefaultResponseErrorHandler on RestTemplate is an instance of HttpServerErrorException, and that does have a getStatusCode() method. You could even route on that using an expression to evaluate against the ErrorMessage payload like this: "payload.cause.statusCode".