Spring/spring-integration
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/master' into 4.0.0-WIP

Browse Source 
Conflicts:
	spring-integration-core/src/test/java/org/springframework/integration/gateway/GatewayInterfaceTests.java
	spring-integration-core/src/test/java/org/springframework/integration/router/config/RouterWithMappingTests.java
	spring-integration-groovy/src/main/java/org/springframework/integration/groovy/GroovyScriptExecutingMessageProcessor.java
	spring-integration-http/src/test/java/org/springframework/integration/http/inbound/HttpRequestHandlingMessagingGatewayWithPathMappingTests.java
	spring-integration-jdbc/src/test/java/org/springframework/integration/jdbc/store/channel/AbstractTxTimeoutMessageStoreTests.java
	spring-integration-jmx/src/main/java/org/springframework/integration/jmx/OperationInvokingMessageHandler.java

Resolved.
This commit is contained in:
Gary Russell
2013-10-30 23:13:27 -04:00
parent e57103466e cc434db959
commit 3080b892d5
93 changed files with 1657 additions and 787 deletions
Download Patch File Download Diff File Expand all files Collapse all files

37
src/reference/docbook/gateway.xml
View File

@@ -187,6 +187,43 @@ public interface Cafe {
</para>
</section>
<section id="gateway-mapping">
<title>Mapping Method Arguments to a Message</title>
<para>
Using the configuration techniques in the previous section allows control of how method arguments are mapped
to message elements (payload and header(s)). When no explicit configuration is used, certain conventions are
used to perform the mapping. In some cases, these conventions cannot determine which argument is the payload
and which should be mapped to headers.
</para>
<programlisting language="java"><![CDATA[
public String send1(Object foo, Map bar);
public String send2(Map foo, Map bar);
]]></programlisting>
<para>
In the first case, the convention will map the first argument to the payload (as long as it is not a
<code>Map</code>) and the contents of the second become headers.
</para>
<para>
In the second case (or the first when the argument for parameter <code>foo</code> is a <code>Map</code>),
the framework cannot determine
which argument should be the payload; mapping will fail. This can generally be resolved using a
<code>payload-expression</code>, a <code>@Payload</code> annotation and/or a <code>@Headers</code>
annotation.
</para>
<para>
Alternatively, and whenever the conventions break down, you can take the entire responsibility for
mapping the method calls to messages. To do this, implement an
<classname>MethodArgsMessageMapper</classname> and provide it to the
<code>&lt;gateway/&gt;</code> using the <code>mapper</code> attribute. The mapper maps a
<classname>MethodArgsHolder</classname>, which is a simple class wrapping the <classname>java.reflect.Method</classname>
instance and an <code>Object[]</code> containing the arguments. When providing a custom mapper,
the <code>default-payload-expression</code> attribute and <code>&lt;default-header/&gt;</code> elements
are not allowed on the gateway; similarly, the <code>payload-expression</code> attribute and
<code>&lt;header/&gt;</code> elements are not allowed on any <code>&lt;method/&gt;</code> elements.
</para>
</section>
<section id="gateway-calling-no-argument-methods">
<title>Invoking No-Argument Methods</title>
<para>

50
src/reference/docbook/http.xml
View File

@@ -354,9 +354,57 @@ By default the HTTP request will be generated using an instance of <classname>Si
</listitem>
</itemizedlist>
<para>
<para>
Since <emphasis>Spring Integration 3.0</emphasis>, in addition to the existing
<code>#pathVariables</code> and <code>#requestParams</code> variables being available in payload and header
expressions, other useful variables have been added.
</para>
<para>
The entire list of available expression variables:
</para>
<itemizedlist>
<listitem>
<emphasis>#requestParams</emphasis> - the <interfacename>MultiValueMap</interfacename> from the
<interfacename>ServletRequest</interfacename> <code>parameterMap</code>.
</listitem>
<listitem>
<emphasis>#pathVariables</emphasis> - the <interfacename>Map</interfacename> from URI Template placeholders and their values;
</listitem>
<listitem>
<emphasis>#matrixVariables</emphasis> - the <interfacename>Map</interfacename> of <interfacename>MultiValueMap</interfacename>
according to
<ulink url="http://docs.spring.io/spring/docs/current/spring-framework-reference/html/mvc.html#mvc-ann-matrix-variables"
>Spring MVC Specification</ulink>. Note, <emphasis>#matrixVariables</emphasis> require Spring MVC 3.2 or higher;
</listitem>
<listitem>
<emphasis>#requestAttributes</emphasis> - the <interfacename>org.springframework.web.context.request.RequestAttributes</interfacename>
associated with the current Request;
</listitem>
<listitem>
<emphasis>#requestHeaders</emphasis> - the <classname>org.springframework.http.HttpHeaders</classname> object from the current Request;
</listitem>
<listitem>
<emphasis>#cookies</emphasis> - the <interfacename>Map&lt;String, Cookie&gt;</interfacename>
of <classname>javax.servlet.http.Cookie</classname>s from the current Request.
</listitem>
</itemizedlist>
<para>
Note, all these values (and others) can be accessed within expressions in the downstream message
flow via the <classname>ThreadLocal</classname> <interfacename>org.springframework.web.context.request.RequestAttributes</interfacename>
variable, if that message flow is single-threaded and lives within the request thread:
</para>
<programlisting language="xml"><![CDATA[<int-:transformer
expression="T(org.springframework.web.context.request.RequestContextHolder).
requestAttributes.request.queryString"/>
]]></programlisting>
</para>
<para><emphasis>Outbound</emphasis></para>
<para>
To configure the outbound gateway you can use the namespace support as well. The following code snippet shows the different configuration options for an outbound Http gateway. Most importantly, notice that the 'http-method' and 'expected-response-type' are provided. Those are two of the most commonly configured values. The
To configure the outbound gateway you can use the namespace support as well.
The following code snippet shows the different configuration options for an outbound Http gateway.
Most importantly, notice that the 'http-method' and 'expected-response-type' are provided. Those are two of the most commonly configured values. The
default http-method is POST, and the default response type is <emphasis>null</emphasis>. With a null response type, the payload of the reply Message would
contain the ResponseEntity as long as it's http status is a success (non-successful status codes will throw Exceptions).
If you are expecting a different type, such as a <classname>String</classname>, then provide that fully-qualified class name as shown below.

9
src/reference/docbook/jdbc.xml
View File

@@ -416,6 +416,7 @@
to configure the associated <classname>Poller</classname> with a
<interfacename>TaskExecutor</interfacename> reference.
</para>
<important>
<para>
Keep in mind, though, that if you use a JDBC backed <emphasis>Message Channel</emphasis> and
you are planning on polling the channel and consequently the message
@@ -426,6 +427,13 @@
threads, may not materialize as expected. For example Apache Derby is
problematic in that regard.
</para>
<para>
To achieve better JDBC queue throughput, and avoid issues when different threads may poll the same
<interfacename>Message</interfacename> from the queue, it is <emphasis role="bold">important</emphasis>
to set the <code>usingIdCache</code> property of <classname>JdbcChannelMessageStore</classname> to <code>true</code>
when using databases that do not support MVCC:
</para>
</important>
<programlisting language="xml"><![CDATA[…
<bean id="queryProvider"
class="o.s.i.jdbc.store.channel.PostgresChannelMessageStoreQueryProvider"/>
@@ -459,6 +467,7 @@
<int:channel id="outputChannel" />
…]]></programlisting>
</section>
<section>
<title>Initializing the Database</title>

18
src/reference/docbook/whats-new.xml
View File

@@ -163,6 +163,10 @@
It is now possible to set common headers across all gateway methods, and more options
are provided for adding, to the message, information about which method was invoked.
</listitem>
<listitem>
It is now possible to entirely customize the way that gateway method calls are mapped
to messages.
</listitem>
</itemizedlist>
</para>
<para>
@@ -244,6 +248,10 @@
to be maintained across JVM executions, a custom filter that retains state, perhaps on
the file system, can now be configured.
</para>
<para>
Inbound Channel Adapters now support the <code>preserve-timestamp</code> attribute, which
sets the local file modified timestamp to the timestamp from the server (default false).
</para>
<para>
For more information, see
<xref linkend="ftp-inbound"/> and <xref linkend="sftp-inbound"/>.
@@ -329,12 +337,20 @@
<interfacename>HttpMessageConverter</interfacename>s after the custom message converters.
</listitem>
<listitem>
<emphasis role="bold">'If-(Un)Modified-Since' HTTP headers</emphasis> - previously,
<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>
<listitem>
<emphasis role="bold">Inbound Endpoint Expression Variables</emphasis> -
In addition to the existing <emphasis>#requestParams</emphasis> and <emphasis>#pathVariables</emphasis>,
the <code>&lt;http:inbound-gateway/&gt;</code> and <code>&lt;http:inbound-channel-adapter/&gt;</code>
now support additional useful variables: <emphasis>#matrixVariables</emphasis>, <emphasis>#requestAttributes</emphasis>,
<emphasis>#requestHeaders</emphasis> and <emphasis>#cookies</emphasis>. These variables are available in
both payload and header expressions.
</listitem>
</itemizedlist>
</para>
<para>