Serialized object problem with HttpRequestHandlingEndpointSupport

[dlaidlaw]

I have wired up an HTTP bridge between two spring integration services as follows. On the sending side (HTTP Client):

    <int-http:outbound-channel-adapter id="httpOut"
         url="http://localhost:8080/bridge/gateway"
	 http-method="POST"
	 channel="toWebChannel"
	 extract-payload="false"  />

In the webapp:

    <int-http:inbound-channel-adapter channel="receiveChannel"
          name="/gateway"
          supported-methods="POST"
    />

The sending has the "extract-payload" property set to false so that the message will be sent serialized, preserving the headers in the message, and more importantly, preserving their case. However, the receiving side does not seem to have an option to specify that the payload is already a serialized message. So it cannot handle this correctly. Note, using a channel adapter because I do not expect a reply.

The

doHandleRequest

method of HttpRequestHandlingEndpointSupport calls generatePayloadFromRequestBody, which correctly chooses the SerializingHttpMessageConverter class to convert the HTTP request body into a Message<?>. However, the HttpRequestHandlingEndpointSupport then attempts to construct a new Message using the MessageBuilder with the Message<?> as the payload. That last part fails.

I can send the messages across without using the SerializingHttpMessageConverter (leave out the extract-payload="false") but then message headers do not preserve their case, since the HTTP Request headers are passed into the header converter un all-lowercase form.

[Mark Fisher]

Could you please open a feature request for this in JIRA? It seems that within HttpRequestHandlingEndpointSupport after deserializing the content of an HTTP request body, we should detect whether that deserialized object is already an instanceof Message.

Does that make sense?

[dlaidlaw]

Yes, it does make sense. The Jira issue is INT-2254: https://jira.springsource.org/browse/INT-2254

It is an improvement issue as requested, but to me it is closer to a bug than an improvement.

[Mark Fisher]

Thanks Don. We are going to try to address it in time for RC1 for which we are trying to "freeze" today.