INT-3142 Allow Merging of HTTP Message Converters

INT-3142: A flag to retain default converters when the user has customized messageconverters for HttpRequestHandlingController, HttpInboundGateway

* Introduced a new flag in the base class of HttpRequHttpRequestHandlingController, HttpInboundGateway - registerDefaultConverters
* Introduced a new attribute "register-default-converters" for inbound-channel-adapter and inbound-gateway to indicate if the default HttpMessageConverter's need to be registered
* Http namespace parser related changes to set the new flag
* Added additional tests to test the flag and the namespace parser related changes

Changes per feedback from Artem - additional javadoc comments, cleaned up tests

Updated: Setting the register-default-converters by default to false now, for backward compatibility reasons
Changed adapter name per feedback from Artem

Changed adapter name per feedback from Artem

Changed attribute name from register-default-converters to merge-with-default-converters

INT-3142: Atomic operation for messageConverters

'What's New' polishing

Polishing

Fix a few comments, error messages, docs, whitespace.
This commit is contained in:
Biju Kunjummen
2013-09-13 20:45:10 -04:00
committed by Gary Russell
parent a9ec7c8107
commit bb6aebc587
12 changed files with 287 additions and 58 deletions

View File

@@ -62,7 +62,9 @@
customization of the mapping from <interfacename>HttpServletRequest</interfacename> to <interfacename>Message</interfacename>. The default converters
encapsulate simple strategies, which for
example will create a String message for a <emphasis>POST</emphasis> request where the content type starts with "text", see the Javadoc for
full details.
full details. An additional flag (<code>mergeWithDefaultConverters</code>) can be set along with the list of
custom <interfacename>HttpMessageConverter</interfacename> to add the default converters after the custom converters.
By default this flag is set to false, meaning that the custom converters replace the default list.
</para>
<para>Starting with this release MultiPart File support was implemented. If the request has been wrapped as a
<emphasis>MultipartHttpServletRequest</emphasis>, when using the default converters, that request will be converted

View File

@@ -233,7 +233,8 @@
<para>
Payloads to <emphasis>persist</emphasis> or
<emphasis>merge</emphasis> can now be of type
<interfacename><ulink url="http://docs.oracle.com/javase/7/docs/api/java/lang/Iterable.html">java.lang.Iterable</ulink></interfacename>.
<interfacename><ulink url="http://docs.oracle.com/javase/7/docs/api/java/lang/Iterable.html"
>java.lang.Iterable</ulink></interfacename>.
</para>
<para>
In that case, each object returned by the
@@ -252,12 +253,33 @@
see 'JSON Transformers' in <xref linkend="transformer"/>.
</para>
</section>
<section id="3.0-http-encode-uri">
<title>HTTP Outbound Endpoint 'encode-uri' property</title>
<section id="3.0-http-endpointss">
<title>HTTP Endpoint Changes</title>
<para>
<code>&lt;http:outbound-gateway/&gt;</code> and <code>&lt;http:outbound-channel-adapter/&gt;</code> now
provide an <code>encode-uri</code> attribute to allow disabling the encoding of the URI object
before sending the request. For more information see <xref linkend="http"/>.
<itemizedlist>
<listitem>
<emphasis role="bold">Outbound Endpoint 'encode-uri'</emphasis> - <code>&lt;http:outbound-gateway/&gt;</code>
and <code>&lt;http:outbound-channel-adapter/&gt;</code> now
provides an <code>encode-uri</code> attribute to allow disabling the encoding of the URI object
before sending the request.
</listitem>
<listitem>
<emphasis role="bold">Inbound Endpoint 'merge-with-default-converters'</emphasis> -
<code>&lt;http:inbound-gateway/&gt;</code> and <code>&lt;http:inbound-channel-adapter/&gt;</code> now
have a <code>merge-with-default-converters</code> attribute to include the list of default
<interfacename>HttpMessageConverter</interfacename> after the custom message converters.
</listitem>
<listitem>
<emphasis role="bold">'If-(Un)Modified-Since' HTTP headers</emphasis> - previously,
'If-Modified-Since' and 'If-Unmodified-Since' HTTP headers were incorrectly processed
within from/to HTTP headers mapping in the <classname>DefaultHttpHeaderMapper</classname>.
Now, in addition correcting that issue, <classname>DefaultHttpHeaderMapper</classname> provides
date parsing from formatted strings for any HTTP headers that accept date-time values.
</listitem>
</itemizedlist>
</para>
<para>
For more information see <xref linkend="http"/>.
</para>
</section>
<section id="3.0-amqp-mapping">
@@ -410,16 +432,6 @@
For more information see <xref linkend="delayer"/>.
</para>
</section>
<section id="3.0-http-header-mapper">
<title>DefaultHttpHeaderMapper and 'If-(Un)Modified-Since' HTTP headers</title>
<para>
Previously, 'If-Modified-Since' and 'If-Unmodified-Since' HTTP headers were incorrectly processed
within from/to HTTP headers mapping in the <classname>DefaultHttpHeaderMapper</classname>.
Now, in addition to the fix of that issue, <classname>DefaultHttpHeaderMapper</classname> provides date parsing
from formatted strings for HTTP headers, which accept date-time values.
For more information see <xref linkend="http"/>.
</para>
</section>
<section id="3.0-pub-sub">
<title>PublishSubscribeChannel Behavior</title>
<para>