HttpRequestHandlingMessagingGateway and response GenericMessage

[Wrangler]

I see in the reference manual it states incoming requests are converted to a Message object:

The HttpRequestHandlingMessagingGateway accepts a list of HttpMessageConverter instances or else relies on a default list. The converters allow customization of the mapping from HttpServletRequest to Message.

This allows me to use Message<String> throughout my code, and the endpoint service-activator returns a Message<String>. The string in the Message payload is XML.

When this Message gets back to the HttpRequestHandlingMessagingGateway, none of the default converters can convert the GenericMessage class to a response to return.

The error is:

Servlet failed with Exception
org.springframework.integration.MessagingException: Could not convert reply: no suitable HttpMessageConverter found for type [org.springframework.integration.MessagingException] and accept types [[*/*]]

The test code I have uses HttpClient 4, with "text/xml" content.

I debugged into the SI code and did not see where this class and its default converters are designed to handle a Message with a String XML, and return the payload XML as a response. Since it has the property 'replyChannel' I assume it would handle this.

Is there something else I need to specify?

This is the context bean:

    <beans:bean id="inboundGateway"
                class="org.springframework.integration.http.inbound.HttpRequestHandlingMessagingGateway">
        <beans:property name="requestChannel" ref="rawXmlRequestChannel"/>
        <beans:property name="replyChannel" ref="outgoingHttpChannel"/>
        <beans:property name="requestTimeout" value="30000"/>
        <beans:property name="replyTimeout" value="10000"/>
        <beans:property name="convertExceptions" value="true" />
    </beans:bean>

And this is in the web.xml:

        <servlet>
            <servlet-name>inboundGateway</servlet-name>
            <servlet-class>org.springframework.web.context.support.HttpRequestHandlerServlet</servlet-class>
            <init-param>
                <param-name>contextConfigLocation</param-name>
                <param-value>classpath:/sif/applicationContext.xml</param-value>
            </init-param>
        </servlet>

        <servlet-mapping>
            <servlet-name>inboundGateway</servlet-name>
            <url-pattern>/*</url-pattern>
        </servlet-mapping>

[oleg.zhurakousky]

Why aren't you using <int-http:inbound-gateway>. This way you'd be able to specify error-channel and handle the exception which would be a payload of an ErrorMessage.
Also, what version are you using?

[Wrangler]

Why aren't you using <int-http:inbound-gateway>. This way you'd be able to specify error-channel and handle the exception which would be a payload of an ErrorMessage.
Also, what version are you using?

This was to be my next question. I started using the <int-http:inbound-gateway>, but I had a HTTP error 503 forbidden, and the deployed war (weblogic) was never called. I switched to using the <bean>, after finding better examples on how to get it to work than I found for the getting the inbound-gateway to work. I figures once I had the <bean> working, its properties would lead to a functioning inbound-gateway.

This is what I was using for the inbound-gateway:

    <int-http:inbound-gateway id="http-inbound-gateway"
                              request-channel="rawXmlRequestChannel"
                              reply-channel="outgoingHttpChannel"
                              request-timeout="30000"
                              reply-timeout="30000"
                              name="/sif"
                              supported-methods="POST, GET"
    />

I am using version 2.0.5.


As for using error-channel with inbound-gateway, I found a forum post from Mark stating:

    Actually, the "error-channel" is not an option on the HTTP inbound gateway since that already
    provides support for HttpMessageConverters that can handle this task. So, the attempt to use
    the HttpMessageConverter is on the right track. Have you tried this with a debugger to ensure
    that it's calling into the canWrite() method and returning true there?

[oleg.zhurakousky]

503 basically means you had some infrastructure error (e.g., your WAR didn't even bootstrapped), so it woud be nice to see as to why?

[Wrangler]

When using the bean, I removed the property: <beansroperty name="extractReplyPayload" value="false"/>, and the payload is now sent back to the client.

Now I need to work on using the inbound-gateway. When using it, do I need any settings in the web.xml file like I did when using HttpRequestHandlingMessagingGateway?

[oleg.zhurakousky]

So what I see is that your request resulted in the exception which is extracted from the ErrorMessage, but there is no HttpConverter to deal with it. So the first question is what would you want to happen?
For example with error-channel option you can receive the entire ErrorMessage, deal with it and return whatever it is you want to return that is compatible with default set of HttpConverters.
Another option would be to add custom HttpConverter to convert MessagingException, but I would prefer the error-channel approach.

[Wrangler]

Using the error-channel approach is what I was thinking of using.

A question I had was would this be a error channel for SI to use, or would my routers, transformers, and service-activators (essentially anything) place error responses (requests for which they are not able to handle) on this same channel?

[oleg.zhurakousky]

Well, the way it works is that whenever exception happens the error is encapsulated into the ErrorMessage and sent to the error-channel. So you can subscribe to he error-channel (after all it is just a channel) and receive the ErrorMessage, get the exception (payload), get the originalMessage (MessagingException.getFailedMessage() ) and produce the output (e.g., String value explaining what went wrong) which (if String for example) would be handle by the default set of HttpConverters and sent back to the client as a reply.
In other words treat error-channel as 'catch' block of try/catch