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:
	build.gradle
	gradle.properties
	spring-integration-core/src/main/java/org/springframework/integration/config/RouterFactoryBean.java
	spring-integration-core/src/test/java/org/springframework/integration/channel/config/DispatchingChannelParserTests.java
	spring-integration-core/src/test/java/org/springframework/integration/gateway/GatewayProxyFactoryBeanTests.java
	spring-integration-core/src/test/java/org/springframework/integration/router/config/PayloadTypeRouterParserTests.java
	spring-integration-core/src/test/java/org/springframework/integration/transformer/MessageTransformingChannelInterceptorTests.java
	spring-integration-ip/src/test/java/org/springframework/integration/ip/tcp/connection/ConnectionFactoryShutDownTests.java
	spring-integration-ip/src/test/java/org/springframework/integration/ip/tcp/connection/TcpNioConnectionReadTests.java
	spring-integration-ip/src/test/java/org/springframework/integration/ip/udp/DatagramPacketSendingHandlerTests.java
	spring-integration-ip/src/test/java/org/springframework/integration/ip/udp/MultiClientTests.java
	spring-integration-ip/src/test/java/org/springframework/integration/ip/udp/UdpChannelAdapterTests.java
	spring-integration-jdbc/src/main/java/org/springframework/integration/jdbc/StoredProcMessageHandler.java
	spring-integration-jdbc/src/main/java/org/springframework/integration/jdbc/StoredProcOutboundGateway.java
	spring-integration-jdbc/src/main/java/org/springframework/integration/jdbc/StoredProcPollingChannelAdapter.java
	spring-integration-xmpp/src/main/java/org/springframework/integration/xmpp/core/AbstractXmppConnectionAwareEndpoint.java

Resolved.
This commit is contained in:
Gary Russell
2013-12-16 11:02:40 -05:00
parent 5ddecd13e7 5ed110c2a0
commit 2baea786b1
77 changed files with 1626 additions and 1685 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
src/reference/docbook/amqp.xml
View File

@@ -282,7 +282,7 @@ this list can also be simple patterns to be matched against the header names (e.
</important>
</section>
<section>
<section id="amqp-outbound-channel-adapter">
<title>Outbound Channel Adapter</title>
<para>A configuration sample for an AMQP Outbound Channel Adapter is shown
@@ -378,7 +378,7 @@ this list can also be simple patterns to be matched against the header names (e.
</para>
</section>
<section>
<section id="amqp-inbound-gateway">
<title>Inbound Gateway</title>
<para>A configuration sample for an AMQP Inbound Gateway is shown
below.</para>
@@ -434,7 +434,7 @@ this list can also be simple patterns to be matched against the header names (e.
</para>
</section>
<section>
<section id="amqp-outbound-gateway">
<title>Outbound Gateway</title>
<para>A configuration sample for an AMQP Outbound Gateway is shown
below.</para>

2
src/reference/docbook/channel-adapter.xml
View File

@@ -84,7 +84,7 @@
</section>
<section id="channel-adapter-namespace-outbound">
<title>Configuring Outbound Channel Adapter</title>
<title>Configuring An Outbound Channel Adapter</title>
<para>
An "outbound-channel-adapter" element can also connect a <interfacename>MessageChannel</interfacename> to any POJO consumer
method that should be invoked with the payload of Messages sent to that channel.

32
src/reference/docbook/channel.xml
View File

@@ -199,17 +199,27 @@
</para>
<para>
The <classname>DirectChannel</classname> internally delegates to a Message Dispatcher to invoke its
subscribed Message Handlers, and that dispatcher can have a load-balancing strategy. The load-balancer
determines how invocations will be ordered in the case that there are multiple handlers subscribed to the
same channel. When using the namespace support described below, the default strategy is
"round-robin" which essentially load-balances across the handlers in rotation.
<note>
The "round-robin" strategy is currently the only implementation available out-of-the-box in Spring
Integration. Other strategy implementations may be added in future versions.
</note>
subscribed Message Handlers, and that dispatcher can have a load-balancing strategy exposed via
<emphasis>load-balancer</emphasis> or <emphasis>load-balancer-ref</emphasis> attributes (mutually exclusive). The load balancing strategy
is used by the Message Dispatcher to help determine how Messages are distributed amongst Message Handlers
in the case that there are multiple Message Handlers subscribed to the same channel.
As a convinience the <emphasis>load-balancer</emphasis> attribute exposes enumeration of values pointing to pre-existing implementations
of <classname>LoadBalancingStrategy</classname>.
The "round-robin" (load-balances across the handlers in rotation) and "none" (for the cases where one wants to explicitely disable load balancing)
are the only available values.
Other strategy implementations may be added in future versions.
However, since version 3.0 you can provide your own implementation of the <classname>LoadBalancingStrategy</classname> and
inject it using <emphasis>load-balancer-ref</emphasis> attribute which should point to a bean that implements
<classname>LoadBalancingStrategy</classname>.
<programlisting language="xml"><![CDATA[<int:channel id="lbRefChannel">
<int:dispatcher load-balancer-ref="lb"/>
</int:channel>
<bean id="lb" class="foo.bar.SampleLoadBalancingStrategy"/>]]></programlisting>
Note that <emphasis>load-balancer</emphasis> or <emphasis>load-balancer-ref</emphasis> attributes are mutually exclusive.
</para>
<para>
The load-balancer also works in combination with a boolean <emphasis>failover</emphasis> property.
The load-balancing also works in combination with a boolean <emphasis>failover</emphasis> property.
If the "failover" value is true (the default), then the dispatcher will fall back to any subsequent
handlers as necessary when preceding handlers throw Exceptions. The order is determined by an optional
order value defined on the handlers themselves or, if no such value exists, the order in which the
@@ -539,8 +549,8 @@ payload to an Integer.
<code>message-store</code> attribute as shown in the next example.
<programlisting language="xml"><![CDATA[<int:channel id="dbBackedChannel">
<int:queue message-store="messageStore">
<int:channel id="myChannel">
<int:queue message-store="messageStore"/>
</int:channel>
<int-jdbc:message-store id="messageStore" data-source="someDataSource"/>]]></programlisting>

225
src/reference/docbook/endpoint-summary.xml Normal file
View File

@@ -0,0 +1,225 @@
<?xml version="1.0" encoding="UTF-8"?>
<chapter xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="endpoint-summary"
xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Endpoint Quick Reference Table</title>
<para>
As discussed in the sections above, Spring Integration provides a number of endpoints used
to interface with external systems, file systems etc. The following is a summary of the various
endpoints with quick links to the appropriate chapter.
</para>
<para>
To recap, <emphasis role="bold">Inbound Channel Adapters</emphasis> are used for one-way integration
bringing data into the messagng application. <emphasis role="bold">Outbound Channel Adapters</emphasis>
are used for one-way integration to send data out of the messaging application.
<emphasis role="bold">Inbound Gateways</emphasis> are used for a bidirectional integration flow where
some other system invokes the messaging application and receives a reply.
<emphasis role="bold">Outbound Gateways</emphasis> are used for a bidirectional integration flow where
the messaging application invokes some external service or entity, expecting a result.
</para>
<table id="endpoint-summary-tbl">
<tgroup cols="5">
<colspec colnum="1" colname="col1" colwidth="1*"/>
<colspec colnum="2" colname="col2" colwidth="1*"/>
<colspec colnum="3" colname="col3" colwidth="1*"/>
<colspec colnum="4" colname="col4" colwidth="1*"/>
<colspec colnum="5" colname="col5"/>
<thead>
<row>
<entry align="center">Module</entry>
<entry align="center">Inbound Adapter</entry>
<entry align="center">Outbound Adapter</entry>
<entry align="center">Inbound Gateway</entry>
<entry align="center">Outbound Gateway</entry>
</row>
</thead>
<tbody>
<row>
<entry><emphasis role="bold">AMQP</emphasis></entry>
<entry><xref linkend="amqp-inbound-channel-adapter" /></entry>
<entry><xref linkend="amqp-outbound-channel-adapter" /></entry>
<entry><xref linkend="amqp-inbound-gateway" /></entry>
<entry><xref linkend="amqp-outbound-gateway" /></entry>
</row>
<row>
<entry><emphasis role="bold">Events</emphasis></entry>
<entry><xref linkend="applicationevent-inbound" /></entry>
<entry><xref linkend="applicationevent-outbound" /></entry>
<entry>N</entry>
<entry>N</entry>
</row>
<row>
<entry><emphasis role="bold">Feed</emphasis></entry>
<entry><xref linkend="feed-inbound-channel-adapter" /></entry>
<entry>N</entry>
<entry>N</entry>
<entry>N</entry>
</row>
<row>
<entry><emphasis role="bold">File</emphasis></entry>
<entry><xref linkend="file-reading" /> and <xref linkend="file-tailing" /></entry>
<entry><xref linkend="file-writing" /></entry>
<entry>N</entry>
<entry><xref linkend="file-writing" /></entry>
</row>
<row>
<entry><emphasis role="bold">FTP(S)</emphasis></entry>
<entry><xref linkend="ftp-inbound" /></entry>
<entry><xref linkend="ftp-outbound" /></entry>
<entry>N</entry>
<entry><xref linkend="ftp-outbound-gateway" /></entry>
</row>
<row>
<entry><emphasis role="bold">Gemfire</emphasis></entry>
<entry><xref linkend="gemfire-inbound" /> and <xref linkend="gemfire-cq" /></entry>
<entry><xref linkend="gemfire-outbound" /></entry>
<entry>N</entry>
<entry>N</entry>
</row>
<row>
<entry><emphasis role="bold">HTTP</emphasis></entry>
<entry><xref linkend="http-namespace" /></entry>
<entry><xref linkend="http-namespace" /></entry>
<entry><xref linkend="http-inbound" /></entry>
<entry><xref linkend="http-outbound" /></entry>
</row>
<row>
<entry><emphasis role="bold">JDBC</emphasis></entry>
<entry><xref linkend="jdbc-inbound-channel-adapter" /> and <xref linkend="stored-procedure-inbound-channel-adapter" /></entry>
<entry><xref linkend="jdbc-outbound-channel-adapter" /> and <xref linkend="stored-procedure-outbound-channel-adapter" /></entry>
<entry>N</entry>
<entry><xref linkend="jdbc-outbound-gateway" /> and <xref linkend="stored-procedure-outbound-gateway" /></entry>
</row>
<row>
<entry><emphasis role="bold">JMS</emphasis></entry>
<entry><xref linkend="jms-inbound-channel-adapter" /> and <xref linkend="jms-message-driven-channel-adapter" /></entry>
<entry><xref linkend="jms-outbound-channel-adapter" /></entry>
<entry><xref linkend="jms-inbound-gateway" /></entry>
<entry><xref linkend="jms-outbound-gateway" /></entry>
</row>
<row>
<entry><emphasis role="bold">JMX</emphasis></entry>
<entry><xref linkend="jmx-notification-listening-channel-adapter" /> and
<xref linkend="jmx-attribute-polling-channel-adapter" /> and
<xref linkend="tree-polling-channel-adapter" /></entry>
<entry><xref linkend="jmx-notification-publishing-channel-adapter" /> and
<xref linkend="jmx-operation-invoking-channel-adapter" /></entry>
<entry>N</entry>
<entry><xref linkend="jmx-operation-invoking-outbound-gateway" /></entry>
</row>
<row>
<entry><emphasis role="bold">JPA</emphasis></entry>
<entry><xref linkend="jpa-inbound-channel-adapter" /></entry>
<entry><xref linkend="jpa-outbound-channel-adapter" /></entry>
<entry>N</entry>
<entry><xref linkend="jpa-updating-outbound-gateway" /> and <xref linkend="jpa-retrieving-outbound-gateway" /></entry>
</row>
<row>
<entry><emphasis role="bold">Mail</emphasis></entry>
<entry><xref linkend="mail-inbound" /></entry>
<entry><xref linkend="mail-outbound" /></entry>
<entry>N</entry>
<entry>N</entry>
</row>
<row>
<entry><emphasis role="bold">MongoDB</emphasis></entry>
<entry><xref linkend="mongodb-inbound-channel-adapter" /></entry>
<entry><xref linkend="mongodb-outbound-channel-adapter" /></entry>
<entry>N</entry>
<entry>N</entry>
</row>
<row>
<entry><emphasis role="bold">Redis</emphasis></entry>
<entry><xref linkend="redis-inbound-channel-adapter" /> and
<xref linkend="redis-queue-inbound-channel-adapter" /> and
<xref linkend="redis-store-inbound-channel-adapter" /></entry>
<entry><xref linkend="redis-outbound-channel-adapter" /> and
<xref linkend="redis-queue-outbound-channel-adapter" /> and
<xref linkend="redis-store-outbound-channel-adapter" /></entry>
<entry>N</entry>
<entry>N</entry>
</row>
<row>
<entry><emphasis role="bold">Resource</emphasis></entry>
<entry><xref linkend="resource-inbound-channel-adapter" /></entry>
<entry>N</entry>
<entry>N</entry>
<entry>N</entry>
</row>
<row>
<entry><emphasis role="bold">RMI</emphasis></entry>
<entry>N</entry>
<entry>N</entry>
<entry><xref linkend="rmi-inbound" /></entry>
<entry><xref linkend="rmi-outbound" /></entry>
</row>
<row>
<entry><emphasis role="bold">SFTP</emphasis></entry>
<entry><xref linkend="sftp-inbound" /></entry>
<entry><xref linkend="sftp-outbound" /></entry>
<entry>N</entry>
<entry><xref linkend="sftp-outbound-gateway" /></entry>
</row>
<row>
<entry><emphasis role="bold">Stream</emphasis></entry>
<entry><xref linkend="stream-reading" /></entry>
<entry><xref linkend="stream-writing" /></entry>
<entry>N</entry>
<entry>N</entry>
</row>
<row>
<entry><emphasis role="bold">Syslog</emphasis></entry>
<entry><xref linkend="syslog-inbound-adapter" /></entry>
<entry>N</entry>
<entry>N</entry>
<entry>N</entry>
</row>
<row>
<entry><emphasis role="bold">TCP</emphasis></entry>
<entry><xref linkend="tcp-adapters" /></entry>
<entry><xref linkend="tcp-adapters" /></entry>
<entry><xref linkend="tcp-gateways" /></entry>
<entry><xref linkend="tcp-gateways" /></entry>
</row>
<row>
<entry><emphasis role="bold">Twitter</emphasis></entry>
<entry><xref linkend="twitter-inbound" /></entry>
<entry><xref linkend="twitter-outbound" /></entry>
<entry>N</entry>
<entry>N</entry>
</row>
<row>
<entry><emphasis role="bold">UDP</emphasis></entry>
<entry><xref linkend="udp-adapters" /></entry>
<entry><xref linkend="udp-adapters" /></entry>
<entry>N</entry>
<entry>N</entry>
</row>
<row>
<entry><emphasis role="bold">Web Services</emphasis></entry>
<entry>N</entry>
<entry>N</entry>
<entry><xref linkend="webservices-inbound" /></entry>
<entry><xref linkend="webservices-outbound" /></entry>
</row>
<row>
<entry><emphasis role="bold">XMPP</emphasis></entry>
<entry><xref linkend="xmpp-messages" /> and <xref linkend="xmpp-presence" /></entry>
<entry><xref linkend="xmpp-messages" /> and <xref linkend="xmpp-presence" /></entry>
<entry>N</entry>
<entry>N</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
In addition, as discussed in <xref linkend="spring-integration-core-messaging" />, endpoints are provided
for interfacing with Plain Old Java Objects
(POJOs). As discussed in <xref linkend="channel-adapter" />, the <code>&lt;int:inbound-channel-adapter&gt;</code>
allows polling a java method for data; the
<code>&lt;int:outbound-channel-adapter&gt;</code> allows sending data to a <code>void</code> method, and
as discussed in <xref linkend="gateway" />, the <code>&lt;int:gateway&gt;</code> allows any Java program
to invoke a messaging flow. Each of these without requiring any source level
dependencies on Spring Integration. The equivalent of an outbound gateway in this context would be to use a
<xref linkend="service-activator" /> to invoke a method that returns an Object of some kind.
</para>
</chapter>

55
src/reference/docbook/feed.xml
View File

@@ -62,55 +62,12 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/feed
Spring Integration provides a convenient mechanism to eliminate the need to worry about duplicate entries.
Each feed entry will have a <emphasis>published date</emphasis> field. Every time a new Message is generated and sent,
Spring Integration will store the value of the latest <emphasis>published date</emphasis> in an instance of the
<classname>org.springframework.integration.metadata.MetadataStore</classname> strategy. The MetadataStore interface is
designed to store various types of generic meta-data (e.g., published date of the last feed entry that has been processed)
to help components such as this Feed adapter deal with duplicates.
<interfacename>MetadataStore</interfacename> strategy (<xref linkend="metadata-store"/>).
</para>
<para>
The default rule for locating this metadata store is as follows:
<emphasis>Spring Integration</emphasis> will look for a bean of type
<classname>org.springframework.integration.metadata.MetadataStore</classname> in
the ApplicationContext. If one is found then it will be used, otherwise
it will create a new instance of <classname>SimpleMetadataStore</classname>
which is an in-memory implementation that will only persist metadata within
the lifecycle of the currently running Application Context. This means
that upon restart you may end up with duplicate entries.
</para>
<para>
If you need to persist metadata between Application Context restarts, two
persistent <interfacename>MetadataStores</interfacename> are available:
</para>
<itemizedlist>
<listitem>PropertiesPersistingMetadataStore</listitem>
<listitem>RedisMetadataStore</listitem>
</itemizedlist>
<para>
The <classname>PropertiesPersistingMetadataStore</classname> is backed by
a properties file and a
<interfacename><ulink url="http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/util/PropertiesPersister.html">PropertiesPersister</ulink></interfacename>.
</para>
<programlisting language="xml"><![CDATA[<bean id="metadataStore"
class="org.springframework.integration.store.PropertiesPersistingMetadataStore"/>]]></programlisting>
<para>
As of <emphasis>Spring Integration 3.0</emphasis> a Redis-based
<interfacename>MetadataStore</interfacename> is also available. For
more information regarding the <classname>RedisMetadataStore</classname>
see <xref linkend="redis-metadata-store" />.
</para>
<warning>
Be careful when using the same Redis instancce across multiple application
contexts as separate Feed adapters may accidentally use the same persisted
key.
</warning>
<para>
Alternatively, you could provide your own implementation of the
<interfacename>MetadataStore</interfacename> interface (e.g. JdbcMetadataStore)
and configure it as bean in the Application Context.
</para>
<note>
The key used to persist the latest <emphasis>published date</emphasis> is the value of the (required)
<code>id</code> attribute of the Feed Inbound Channel Adapter component plus the <code>feedUrl</code>
from the adapter's configuration.
</note>
<note>
The key used to persist the latest <emphasis>published date</emphasis> is the value of the (required)
<code>id</code> attribute of the Feed Inbound Channel Adapter component plus the <code>feedUrl</code>
from the adapter's configuration.
</note>
</section>
</chapter>

5
src/reference/docbook/file.xml
View File

@@ -39,9 +39,8 @@
The <classname>AcceptOnceFileListFilter</classname> stores its state in memory. If you wish the
state to survive a system restart, consider using the
<classname>FileSystemPersistentAcceptOnceFileListFilter</classname> instead. This filter stores
the accepted file names in a <interfacename>MetadataStore</interfacename>. The framework supplies
several store implementations (such as Redis), or you can provide your own. This filter matches on
the filename and modified time.
the accepted file names in a <interfacename>MetadataStore</interfacename> strategy (<xref linkend="metadata-store"/>).
This filter matches on the filename and modified time.
</note>
<programlisting language="xml"><![CDATA[<bean id="pollableFileSource"
class="org.springframework.integration.file.FileReadingMessageSource"

12
src/reference/docbook/ftp.xml
View File

@@ -192,10 +192,10 @@ protected void postProcessClientBeforeConnect(T client) throws IOException {
The <classname>AcceptOnceFileListFilter</classname> stores its state in memory. If you wish the
state to survive a system restart, consider using the
<classname>FtpPersistentAcceptOnceFileListFilter</classname> instead. This filter stores
the accepted file names in a <interfacename>MetadataStore</interfacename>. The framework supplies
several store implementations (such as Redis), or you can provide your own. This filter matches on
the filename and the remote modified time.
</para>
the accepted file names in an instance of the
<interfacename>MetadataStore</interfacename> strategy (<xref linkend="metadata-store"/>).
This filter matches on the filename and the remote modified time.
</para>
<note>
<para>
Beginning with <emphasis>version 3.0</emphasis>, you can also specify a filter used to filter the files locally, once they have
@@ -208,8 +208,8 @@ protected void postProcessClientBeforeConnect(T client) throws IOException {
The <classname>AcceptOnceFileListFilter</classname> stores its state in memory. If you wish the
state to survive a system restart, consider using the
<classname>FileSystemPersistentAcceptOnceFileListFilter</classname> as a local filter instead. This filter stores
the accepted file names in a <interfacename>MetadataStore</interfacename>. The framework supplies
several store implementations (such as Redis), or you can provide your own.
the accepted file names in an instance of the
<interfacename>MetadataStore</interfacename> strategy (<xref linkend="metadata-store"/>).
<important>
This filter compares the filename and modified timestamp. If you wish to use this technique to avoid a
re-synchronized file from being processed, you should use the <code>preserve-timestamp</code> attribute discussed above.

6
src/reference/docbook/gemfire.xml
View File

@@ -28,7 +28,7 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/gemfire
http://www.springframework.org/schema/integration/gemfire/spring-integration-gemfire.xsd"]]></programlisting>
</para>
</section>
<section>
<section id="gemfire-inbound">
<title>Inbound Channel Adapter</title>
<para>
The <emphasis>inbound-channel-adapter</emphasis> produces messages on a channel triggered by a GemFire <classname>EntryEvent</classname>. GemFire
@@ -49,7 +49,7 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/gemfire
If <code>expression</code> is not provided the message payload will be a GemFire <classname>EntryEvent</classname>
</para>
</section>
<section>
<section id="gemfire-cq">
<title>Continuous Query Inbound Channel Adapter</title>
<para>
The <emphasis>cq-inbound-channel-adapter</emphasis> produces messages a channel triggered by a GemFire continuous query or <classname>CqEvent</classname> event. Spring GemFire introduced
@@ -90,7 +90,7 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/gemfire
</para>
</section>
<section>
<section id="gemfire-outbound">
<title>Outbound Channel Adapter</title>
<para>
The <emphasis>outbound-channel-adapter</emphasis> writes cache entries mapped from the message payload. In its simplest form, it expects a

9
src/reference/docbook/handler-advice.xml
View File

@@ -295,10 +295,11 @@ Caused by: java.lang.RuntimeException: foo
<para>
Spring Retry has a great deal of flexibility for determining which
exceptions can invoke retry. The default configuration will retry
for all exceptions. Given that, user exceptions may be wrapped in
a <classname>MessagingException</classname> in the underlying handler,
we need to ensure that the classification examines the exception causes.
The default classifier just looks at the top level exception.
for all exceptions and the exception classifier just looks at the
top level exception. If you configure it to, say, only retry
on <classname>BarException</classname> and your application throws
a <classname>FooException</classname> where the cause is a
<classname>BarException</classname>, retry will not occur.
</para>
<para>
Since <emphasis>Spring Retry 1.0.3</emphasis>, the

5
src/reference/docbook/index.xml
View File

@@ -115,12 +115,13 @@
<xi:include href="./system-management.xml"/>
</part>
<part id="spring-integration-adapters">
<title>Integration Adapters</title>
<title>Integration Endpoints</title>
<partintro id="spring-integration-adapters">
<para>This section covers the various Channel Adapters and Messaging Gateways provided
by Spring Integration to support Message-based communication with external systems.
</para>
</partintro>
<xi:include href="./endpoint-summary.xml"/>
<xi:include href="./amqp.xml"/>
<xi:include href="./event.xml"/>
<xi:include href="./feed.xml"/>
@@ -128,7 +129,6 @@
<xi:include href="./ftp.xml"/>
<xi:include href="./gemfire.xml"/>
<xi:include href="./http.xml"/>
<xi:include href="./ip.xml"/>
<xi:include href="./jdbc.xml"/>
<xi:include href="./jpa.xml"/>
<xi:include href="./jms.xml"/>
@@ -140,6 +140,7 @@
<xi:include href="./sftp.xml"/>
<xi:include href="./stream.xml"/>
<xi:include href="./syslog.xml"/>
<xi:include href="./ip.xml"/>
<xi:include href="./twitter.xml"/>
<xi:include href="./ws.xml"/>
<xi:include href="./xml.xml"/>

68
src/reference/docbook/meta-data-store.xml Normal file
View File

@@ -0,0 +1,68 @@
<?xml version="1.0" encoding="UTF-8"?>
<section xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="metadata-store"
xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Metadata Store</title>
<para>
Many external systems, services or resources aren't transactional (Twitter, RSS, file system etc.)
and there is no any ability to mark the data as read. Or there is just need to implement the
Enterprise Integration Pattern <ulink url="http://eaipatterns.com/IdempotentReceiver.html">Idempotent Receiver</ulink>
in some integration solutions. To achieve this goal and store some previous state of the Endpoint before the next
interaction with external system, or deal with the next Message, Spring Integration provides the <emphasis>Metadata Store</emphasis>
component being an implementation of the <interfacename>org.springframework.integration.metadata.MetadataStore</interfacename>
interface with a general <emphasis>key-value</emphasis> contract.
</para>
<para>
The <emphasis>Metadata Store</emphasis> is designed to store various types of generic meta-data
(e.g., published date of the last feed entry that has been processed) to help components such as the Feed adapter deal with duplicates.
If a component is not directly provided with a reference to a <interfacename>MetadataStore</interfacename>,
the algorithm for locating a metadata store is as follows: First, look for a bean with id
<code>metadataStore</code> in the ApplicationContext. If one is found then it will be used, otherwise
it will create a new instance of <classname>SimpleMetadataStore</classname> which is an in-memory implementation
that will only persist metadata within the lifecycle of the currently running Application Context. This means
that upon restart you may end up with duplicate entries.
</para>
<para>
If you need to persist metadata between Application Context restarts, two
persistent <interfacename>MetadataStores</interfacename> are provided by the framework:
</para>
<itemizedlist>
<listitem>PropertiesPersistingMetadataStore</listitem>
<listitem><xref linkend="redis-metadata-store"/></listitem>
</itemizedlist>
<para>
The <classname>PropertiesPersistingMetadataStore</classname> is backed by a properties file and a
<interfacename><ulink url="http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/util/PropertiesPersister.html">PropertiesPersister</ulink></interfacename>.
</para>
<programlisting language="xml"><![CDATA[<bean id="metadataStore"
class="org.springframework.integration.store.PropertiesPersistingMetadataStore"/>]]></programlisting>
<para>
Alternatively, you can provide your own implementation of the
<interfacename>MetadataStore</interfacename> interface (e.g. JdbcMetadataStore)
and configure it as a bean in the Application Context.
</para>
<section id="idempotent-receiver">
<title>Idempotent Receiver</title>
<para>
The <emphasis>Metadata Store</emphasis> is useful for implementating the
EIP <ulink url="http://eaipatterns.com/IdempotentReceiver.html">Idempotent Receiver</ulink> pattern, when
there is need to <emphasis>filter</emphasis> an incoming Message if it has already been processed, and just discard
it or perform some other logic on discarding. The following configuration is an example of how to do this:
</para>
<programlisting language="xml"><![CDATA[<int:filter input-channel="serviceChannel"
output-channel="idempotentServiceChannel"
discard-channel="discardChannel"
expression="@metadataStore.get(headers.businessKey) == null"/>
<int:publish-subscribe-channel id="idempotentServiceChannel"/>
<int:outbound-channel-adapter channel="idempotentServiceChannel"
expression="@metadataStore.put(headers.businessKey, '')"/>
<int:service-activator input-channel="idempotentServiceChannel" ref="service"/>]]></programlisting>
<para>
The <code>value</code> of the idempotent entry may be some expiration date, after which that entry should
be removed from <emphasis>Metadata Store</emphasis> by some scheduled reaper.
</para>
</section>
</section>

26
src/reference/docbook/redis.xml
View File

@@ -424,15 +424,18 @@ rt.setConnectionFactory(redisConnectionFactory);]]></programlisting>
<title>Redis Metadata Store</title>
<para>
As of <emphasis>Spring Integration 3.0</emphasis> a new Redis-based
<interfacename><ulink url="http://docs.spring.io/spring-integration/docs/latest-ga/api/org/springframework/integration/store/MetadataStore.html">MetadataStore</ulink></interfacename>
implementation is available. The <classname>RedisMetadataStore</classname> can
<interfacename><ulink url="http://docs.spring.io/spring-integration/docs/latest-ga/api/org/springframework/integration/metadata/MetadataStore.html">MetadataStore</ulink></interfacename>
(<xref linkend="metadata-store"/>) implementation is available. The <classname>RedisMetadataStore</classname> can
be used to maintain state of a <interfacename>MetadataStore</interfacename>
across application restarts. This new <interfacename>MetadataStore</interfacename>
implementation can be used with adapters such as:
</para>
<itemizedlist>
<listitem>Twitter Inbound Adapters</listitem>
<listitem>Feed Inbound Channel Adapter</listitem>
<listitem><xref linkend="twitter-inbound"/></listitem>
<listitem><xref linkend="feed-inbound-channel-adapter"/></listitem>
<listitem><xref linkend="file-reading"/></listitem>
<listitem><xref linkend="ftp-inbound"/></listitem>
<listitem><xref linkend="sftp-inbound"/></listitem>
</itemizedlist>
<para>
In order to instruct these adapters to use the new <classname>RedisMetadataStore</classname>
@@ -444,11 +447,16 @@ rt.setConnectionFactory(redisConnectionFactory);]]></programlisting>
<programlisting language="xml"><![CDATA[<bean name="metadataStore" class="o.s.i.redis.store.metadata.RedisMetadataStore">
<constructor-arg name="connectionFactory" ref="redisConnectionFactory"/>
</bean>]]></programlisting>
<warning>
Be careful when using the same Redis instancce across multiple application
contexts as separate adapters may accidentally use the same persisted
key.
</warning>
<para>
The <classname>RedisMetadataStore</classname> is backed by
<ulink url="http://docs.spring.io/spring-data/data-redis/docs/current/api/org/springframework/data/redis/support/collections/RedisProperties.html"
><classname>RedisProperties</classname></ulink> and interaction with it uses
<ulink url="http://docs.spring.io/spring-data/data-redis/docs/current/api/org/springframework/data/redis/core/BoundHashOperations.html"
><classname>BoundHashOperations</classname></ulink>, which, in turn, requires a <code>key</code> for the entire
<classname>Properties</classname> store. In the case of the <interfacename>MetadataStore</interfacename>, this
<code>key</code> plays the role of a <emphasis>region</emphasis>, which is useful in distributed environment,
when several applications use the same Redis server. By default this <code>key</code> has the value <code>MetaData</code>.
</para>
</section>
<section id="redis-store-inbound-channel-adapter">
<title>RedisStore Inbound Channel Adapter</title>

12
src/reference/docbook/sftp.xml
View File

@@ -317,10 +317,10 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/sftp
The <classname>AcceptOnceFileListFilter</classname> stores its state in memory. If you wish the
state to survive a system restart, consider using the
<classname>SftpPersistentAcceptOnceFileListFilter</classname> instead. This filter stores
the accepted file names in a <interfacename>MetadataStore</interfacename>. The framework supplies
several store implementations (such as Redis), or you can provide your own. This filter matches on
the filename and the remote modified time.
</para>
the accepted file names in an instance of the
<interfacename>MetadataStore</interfacename> strategy (<xref linkend="metadata-store"/>).
This filter matches on the filename and the remote modified time.
</para>
<note>
<para>
Beginning with <emphasis>version 3.0</emphasis>, you can also specify a filter used to filter the files locally, once they have
@@ -333,8 +333,8 @@ xsi:schemaLocation="http://www.springframework.org/schema/integration/sftp
The <classname>AcceptOnceFileListFilter</classname> stores its state in memory. If you wish the
state to survive a system restart, consider using the
<classname>FileSystemPersistentAcceptOnceFileListFilter</classname> as a local filter instead. This filter stores
the accepted file names in a <interfacename>MetadataStore</interfacename>. The framework supplies
several store implementations (such as Redis), or you can provide your own.
the accepted file names in an instance of the
<interfacename>MetadataStore</interfacename> strategy (<xref linkend="metadata-store"/>).
<important>
This filter compares the filename and modified timestamp. If you wish to use this technique to avoid a
re-synchronized file from being processed, you should use the <code>preserve-timestamp</code> attribute discussed above.

3
src/reference/docbook/system-management.xml
View File

@@ -3,10 +3,11 @@
xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns:xlink="http://www.w3.org/1999/xlink">
<title>System Management</title>
<xi:include href="./jmx.xml"/>
<xi:include href="./message-history.xml"/>
<xi:include href="./message-store.xml"/>
<xi:include href="./meta-data-store.xml"/>
<xi:include href="./control-bus.xml"/>
<xi:include href="./shutdown.xml"/>

32
src/reference/docbook/twitter.xml
View File

@@ -148,34 +148,8 @@ twitter.oauth.accessTokenSecret=AbRxUAvyNCtqQtxFK8w5ZMtMj20KFhB6o]]></programlis
criteria you'll end up with the same set of tweets unless some other new tweet that matches your search criteria was posted
in between your searches. In that situation you'll get all the tweets you had before plus the new one. But what you really
want is only the new tweet(s). Spring Integration provides an elegant mechanism for handling these situations.
The latest Tweet id will be stored in an instance of the <classname>org.springframework.integration.metadata.MetadataStore</classname> which is a
strategy interface designed for storing various types of metadata (e.g., last retrieved tweet in this case). That strategy helps components such as
these Twitter adapters avoid duplicates. By default, Spring Integration will look for a bean of type
<classname>org.springframework.integration.metadata.MetadataStore</classname> in the ApplicationContext. Alternatively,
you can configure an explicit <classname>MetadataStore</classname> on the adapter.
If there is no explicit or default store, the adapter will create a new instance of <classname>SimpleMetadataStore</classname>
which is a simple in-memory implementation that will only persist metadata within the lifecycle of the currently running application context.
That means upon restart you may end up with duplicate entries. If you need to persist metadata between Application Context
restarts, you may use the <classname>PropertiesPersistingMetadataStore</classname> (which is backed by a properties file, and a persister
strategy), or you may create your own custom implementation of the <classname>MetadataStore</classname> interface (e.g., JdbcMetadatStore)
and configure it as a bean named 'metadataStore' within the Application Context.
</para>
<para>
As of <emphasis>Spring Integration 3.0</emphasis> a Redis-based
<interfacename>MetadataStore</interfacename> is available. The
<classname>RedisMetadataStore</classname> allows you to maintain persisted
metadata across Application Context restarts. For more information see <xref linkend="redis-metadata-store" />.
</para>
<warning>
Be careful when using the same Redis instance across multiple application
contexts as separate Twitter adapters may accidentally use the same persisted
key.
</warning>
<programlisting language="xml"><![CDATA[<bean id="metadataStore" class="o.s.i.store.PropertiesPersistingMetadataStore"/>
]]></programlisting>
<para>
If the <classname>MetadataStore</classname> is persistent, during initialization, any Inbound Twitter Adapter (see below)
will retrieve the latest tweet id that has already been sent by the adapter.
The latest Tweet id will be stored in an instance of the <classname>org.springframework.integration.metadata.MetadataStore</classname>
strategy (e.g. last retrieved tweet in this case). For more information see <xref linkend="metadata-store"/>.
</para>
<note>
The key used to persist the latest <emphasis>twitter id</emphasis> is the value of the (required)
@@ -232,7 +206,7 @@ twitter.oauth.accessTokenSecret=AbRxUAvyNCtqQtxFK8w5ZMtMj20KFhB6o]]></programlis
</para>
<para>
Here is a link that will help you learn more about Twitter queries: http://search.twitter.com/operators
Refer to <ulink url="https://dev.twitter.com/docs/using-search" /> to learn more about Twitter queries.
</para>
</section>
<para>

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

@@ -5,104 +5,25 @@
<title>What's new in Spring Integration 3.0?</title>
<para>
This chapter provides an overview of the new features and improvements
that have been introduced with Spring Integration 3.0 If you are interested
in even more detail, please take a look at the Issue Tracker tickets that
that have been introduced with Spring Integration 3.0. If you are interested
in more details, please see the Issue Tracker tickets that
were resolved as part of the 3.0 development process.
</para>
<section id="3.0-new-components">
<title>New Components</title>
<section id="3.0-tcp-events">
<title>TCP/IP Connection Events and Connection Management</title>
<section id="3.0-request-mapping">
<title>HTTP Request Mapping</title>
<para>
The (supplied) <classname>TcpConnection</classname>s now emit
<interfacename>ApplicationEvent</interfacename>s (specifically
<classname>TcpConnectionEvent</classname>s) when connections are
opened, closed, or an exception occurs. This allows applications
to be informed of changes to TCP connections using the normal
Spring <interfacename>ApplicationListener</interfacename>
mechanism.
</para>
<para>
<classname>AbstractTcpConnection</classname> has been renamed
<classname>TcpConnectionSupport</classname>; custom connections that
are subclasses of this class, can use its methods to publish events.
Similarly, <classname>AbstractTcpConnectionInterceptor</classname> has
been renamed to <classname>TcpConnectionInterceptorSupport</classname>.
</para>
<para>
In addition, a new <code>&lt;int-ip:tcp-connection-event-inbound-channel-adapter/&gt;</code>
is provided; by default, this adapter sends all <classname>TcpConnectionEvent</classname>s
to a <interfacename>Channel</interfacename>.
</para>
<para>
Further, the TCP Connection Factories, now provide a new method
<code>getOpenConnectionIds()</code>, which returns a list of identifiers for all
open connections; this allows applications, for example, to broadcast to all
open connections.
</para>
<para>
Finally, the connection factories also provide a new method
<code>closeConnection(String connectionId)</code> which allows applications
to explicitly close a connection using its ID.
</para>
<para>
For more information see <xref linkend="tcp-events"/>.
</para>
</section>
<section id="3.0-syslog">
<title>Syslog Support</title>
<para>
Building on the 2.2 <classname>SyslogToMapTransformer</classname> Spring
Integration 3.0 now introduces
<code>UDP</code> and <code>TCP</code> inbound channel adapters especially tailored
for receiving SYSLOG messages. For more information, see
<xref linkend="syslog"/>.
</para>
</section>
<section id="3.0-jmx">
<title>JMX Support</title>
<para>
<itemizedlist>
<listitem>
A new <code>&lt;int-jmx:tree-polling-channel-adapter/&gt;</code> is provided; this
adapter queries the JMX MBean tree and sends a message with a payload that is the
graph of objects that matches the query. By default the MBeans are mapped to
primitives and simple Objects like Map, List and arrays - permitting simple
transformation, for example, to JSON.
</listitem>
<listitem>
The <classname>IntegrationMBeanExporter</classname> now allows the configuration of
a custom <classname>ObjectNamingStrategy</classname> using the <code>naming-strategy</code>
attribute.
</listitem>
</itemizedlist>
</para>
<para>
For more information, see <xref linkend="jmx"/>.
</para>
</section>
<section id="3.0-tail">
<title>'Tail' Support</title>
<para>
File 'tail'ing inbound channel adapters are now provided to generate messages when
lines are added to the end of text files; see <xref linkend="file-tailing"/>.
</para>
</section>
<section id="3.0-inbound-script">
<title>Inbound Channel Adapter Script Support</title>
<para>
The <code>&lt;int:inbound-channel-adapter/&gt;</code> now supports <code>&lt;expression/&gt;</code>
and <code>&lt;script/&gt;</code> sub-elements to create a
<interfacename>MessageSource</interfacename>; see <xref linkend="channel-adapter-expressions-and-scripts"/>.
</para>
</section>
<section id="3.0-content-enricher-headers">
<title>Content Enricher: Headers Enrichment Support</title>
<para>
The Content Enricher now provides configuration for <code>&lt;header/&gt;</code>
sub-elements, to enrich the outbound Message with headers based on the reply Message from the underlying
message flow. For more information see <xref linkend="payload-enricher"/>.
The HTTP module now provides powerful Request Mapping support for Inbound Endpoints. Class <classname>UriPathHandlerMapping</classname>
was replaced by <classname>IntegrationRequestMappingHandlerMapping</classname>, which is registered under the bean name
<code>integrationRequestMappingHandlerMapping</code> in the application context. Upon parsing of the HTTP Inbound Endpoint,
a new <classname>IntegrationRequestMappingHandlerMapping</classname> bean is either registered or an existing bean is being reused.
To achieve flexible Request Mapping configuration, Spring Integration provides the <code>&lt;request-mapping/&gt;</code>
sub-element for the <code>&lt;http:inbound-channel-adapter/&gt;</code> and the <code>&lt;http:inbound-gateway/&gt;</code>.
Both HTTP Inbound Endpoints are now fully based on the Request Mapping infrastructure that was introduced with Spring MVC 3.1.
For example, multiple paths are supported on a single inbound endpoint.
For more information see <xref linkend="http-namespace"/>.
</para>
</section>
<section id="3.0-spel-customization">
@@ -131,20 +52,6 @@
For more information see <xref linkend="spel-property-accessors" />.
</para>
</section>
<section id="3.0-request-mapping">
<title>HTTP Request Mapping</title>
<para>
The HTTP module now provides powerful Request Mapping support for Inbound Endpoints. Class <classname>UriPathHandlerMapping</classname>
was replaced by <classname>IntegrationRequestMappingHandlerMapping</classname>, which is registered under the bean name
<code>integrationRequestMappingHandlerMapping</code> in the application context. Upon parsing of the HTTP Inbound Endpoint,
a new <classname>IntegrationRequestMappingHandlerMapping</classname> bean is either registered or an existing bean is being reused.
To achieve flexible Request Mapping configuration, Spring Integration provides the <code>&lt;request-mapping/&gt;</code>
sub-element for <code>&lt;http:inbound-channel-adapter/&gt;</code> and <code>&lt;http:inbound-gateway/&gt;</code>.
Both HTTP Inbound Endpoints are now fully based on the Request Mapping infrastructure that was introduced with Spring MVC 3.1.
For example, multiple paths are supported on a single inbound endpoint.
For more information see <xref linkend="http-namespace"/>.
</para>
</section>
<section id="3.0-redis-new-components">
<title>Redis: New Components</title>
<para>
@@ -191,11 +98,113 @@
See <xref linkend="mongodb"/> for more information.
</para>
</section>
<section id="3.0-syslog">
<title>Syslog Support</title>
<para>
Building on the 2.2 <classname>SyslogToMapTransformer</classname> Spring
Integration 3.0 now introduces
<code>UDP</code> and <code>TCP</code> inbound channel adapters especially tailored
for receiving SYSLOG messages. For more information, see
<xref linkend="syslog"/>.
</para>
</section>
<section id="3.0-tail">
<title>'Tail' Support</title>
<para>
File 'tail'ing inbound channel adapters are now provided to generate messages when
lines are added to the end of text files; see <xref linkend="file-tailing"/>.
</para>
</section>
<section id="3.0-jmx">
<title>JMX Support</title>
<para>
<itemizedlist>
<listitem>
A new <code>&lt;int-jmx:tree-polling-channel-adapter/&gt;</code> is provided; this
adapter queries the JMX MBean tree and sends a message with a payload that is the
graph of objects that matches the query. By default the MBeans are mapped to
primitives and simple Objects like Map, List and arrays - permitting simple
transformation, for example, to JSON.
</listitem>
<listitem>
The <classname>IntegrationMBeanExporter</classname> now allows the configuration of
a custom <classname>ObjectNamingStrategy</classname> using the <code>naming-strategy</code>
attribute.
</listitem>
</itemizedlist>
</para>
<para>
For more information, see <xref linkend="jmx"/>.
</para>
</section>
<section id="3.0-tcp-events">
<title>TCP/IP Connection Events and Connection Management</title>
<para>
<classname>TcpConnection</classname>s now emit
<interfacename>ApplicationEvent</interfacename>s (specifically
<classname>TcpConnectionEvent</classname>s) when connections are
opened, closed, or an exception occurs. This allows applications
to be informed of changes to TCP connections using the normal
Spring <interfacename>ApplicationListener</interfacename>
mechanism.
</para>
<para>
<classname>AbstractTcpConnection</classname> has been renamed
<classname>TcpConnectionSupport</classname>; custom connections that
are subclasses of this class, can use its methods to publish events.
Similarly, <classname>AbstractTcpConnectionInterceptor</classname> has
been renamed to <classname>TcpConnectionInterceptorSupport</classname>.
</para>
<para>
In addition, a new <code>&lt;int-ip:tcp-connection-event-inbound-channel-adapter/&gt;</code>
is provided; by default, this adapter sends all <classname>TcpConnectionEvent</classname>s
to a <interfacename>Channel</interfacename>.
</para>
<para>
Further, the TCP Connection Factories, now provide a new method
<code>getOpenConnectionIds()</code>, which returns a list of identifiers for all
open connections; this allows applications, for example, to broadcast to all
open connections.
</para>
<para>
Finally, the connection factories also provide a new method
<code>closeConnection(String connectionId)</code> which allows applications
to explicitly close a connection using its ID.
</para>
<para>
For more information see <xref linkend="tcp-events"/>.
</para>
</section>
<section id="3.0-inbound-script">
<title>Inbound Channel Adapter Script Support</title>
<para>
The <code>&lt;int:inbound-channel-adapter/&gt;</code> now supports <code>&lt;expression/&gt;</code>
and <code>&lt;script/&gt;</code> sub-elements to create a
<interfacename>MessageSource</interfacename>; see <xref linkend="channel-adapter-expressions-and-scripts"/>.
</para>
</section>
<section id="3.0-content-enricher-headers">
<title>Content Enricher: Headers Enrichment Support</title>
<para>
The Content Enricher now provides configuration for <code>&lt;header/&gt;</code>
sub-elements, to enrich the outbound Message with headers based on the reply Message from the underlying
message flow. For more information see <xref linkend="payload-enricher"/>.
</para>
</section>
</section>
<section id="3.0-general">
<title>General Changes</title>
<section id="3.0-message-id">
<title>Message ID Generation</title>
<para>
Previously, message ids were generated using the JDK <code>UUID.randomUUID()</code> method. With this
release, the default mechanism has been changed to use a more efficient algorithm which
is significantly faster. In addition, the ability to change
the strategy used to generate message ids has been added.
For more information see <xref linkend="message-id-generation"/>.
</para>
</section>
<section id="3.0-gateway">
<title>&lt;gateway&gt; Changes</title>
<para>
@@ -208,204 +217,16 @@
It is now possible to entirely customize the way that gateway method calls are mapped
to messages.
</listitem>
<listitem>
The <classname>GatewayMethodMetadata</classname> is now public class and it makes possible flexibly
to configure the <classname>GatewayProxyFactoryBean</classname> programmatically from Java code.
</listitem>
</itemizedlist>
</para>
<para>
For more information see <xref linkend="gateway"/>.
</para>
</section>
<section id="3.0-corr-endpoint-empty-groups">
<title>Aggregator 'empty-group-min-timeout' property</title>
<para><classname>AbstractCorrelatingMessageHandler</classname> provides a new property
<code>empty-group-min-timeout</code>
to allow empty group expiry to run on a longer schedule than expiring partial groups. Empty groups will
not be removed from the <interfacename>MessageStore</interfacename> until they have not been modified
for at least this number of milliseconds. For more information see <xref linkend="aggregator-config"/>.
</para>
</section>
<section id="3.0-advising-filters">
<title>Advising Filters</title>
<para>
Previously, when a &lt;filter/&gt; had a &lt;request-handler-advice-chain/&gt;, the discard
action was all performed within the scope of the advice chain (including any downstream flow
on the <code>discard-channel</code>). The filter element now has an attribute
<code>discard-within-advice</code> (default <code>true</code>), to allow the discard action to
be performed after the advice chain completes. See <xref linkend="advising-filters"/>.
</para>
</section>
<section id="3.0-annotation-advice">
<title>Advising Endpoints using Annotations</title>
<para>
Request Handler Advice Chains can now be configured using annotations. See
<xref linkend="advising-with-annotations"/>.
</para>
</section>
<section id="3.0-o-t-s-t">
<title>ObjectToStringTransformer Improvements</title>
<para>
This transformer now correctly transforms <code>byte[]</code> and <code>char[]</code>
payloads to <classname>String</classname>. For more information see <xref linkend="transformer"/>.
</para>
</section>
<section id="3.0-ws-outbound-uri-substitution">
<title>Web Service Outbound URI Configuration</title>
<para>
Web Service Outbound Gateway 'uri' attribute now supports <code>&lt;uri-variable/&gt;</code> substitution for all
URI-schemes supported by Spring Web Services. For more information see <xref linkend="outbound-uri"/>.
</para>
</section>
<section id="3.0-ftp-cache-changes">
<title>FTP, SFTP and FTPS Cached Sessions</title>
<para>
The FTP, SFTP and FTPS endpoints no longer cache sessions by default.
</para>
<para>
The deprecated <code>cached-sessions</code> attribute has been removed from all endpoints.
Previously, the embedded caching mechanism controlled by this attribute's value didn't
provide a way to limit the size of the cache, which could
grow indefinitely. The <classname>CachingConnectionFactory</classname> was introduced in
release 2.1 and it became the preferred (and is now the only) way to cache sessions.
For more information, see
<xref linkend="ftp-session-caching"/> and <xref linkend="sftp-session-caching"/>.
</para>
<para>
The <classname>CachingConnectionFactory</classname> now provides a new method
<code>resetCache()</code>. This immediately closes idle sessions and causes in-use
sessions to be closed as and when they are returned to the cache.
</para>
<para>
The <classname>DefaultSftpSessionFactory</classname> (in conjunction with a
<classname>CachingSessionFactory</classname>) now supports multiplexing channels over
a single SSH connection (SFTP Only).
</para>
</section>
<section id="3.0-xFTP-ib">
<title>FTP, SFTP and FTPS Inbound Adapters</title>
<para>
Previously, there was no way to override the default filter used to process files retrieved
from a remote server. The <code>filter</code> attribute determines which files are retrieved
but the <classname>FileReadingMessageSource</classname> uses an
<classname>AcceptOnceFileListFilter</classname>. This means that if a new copy of a file
is retrieved, with the same name as a previously copied file, no message was sent from the
adapter.
</para>
<para>
With this release, a new attribute <code>local-filter</code> allows you to override the
default filter, for example with an <classname>AcceptAllFileListFilter</classname>, or some
other custom filter.
</para>
<para>
For users that wish the behavior of the <classname>AcceptOnceFileListFilter</classname>
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"/>.
</para>
</section>
<section id="3.0-xFTP-gw">
<title>FTP, SFTP and FTPS Gateways</title>
<para>
<itemizedlist>
<listitem>
The gateways now support the <emphasis role="bold">mv</emphasis> command, enabling
the renaming of remote files.
</listitem>
<listitem>
The gateways now support recursive <emphasis role="bold">ls</emphasis> and
<emphasis role="bold">mget</emphasis> commands, enabling
the retrieval of a remote file tree.
</listitem>
<listitem>
The gateways now support <emphasis role="bold">put</emphasis> and
<emphasis role="bold">mput</emphasis> commands, enabling
sending file(s) to the remote server.
</listitem>
<listitem>
The <code>local-filename-generator-expression</code> attribute is now supported,
enabling the naming of local files during retrieval. By default, the same
name as the remote file is used.
</listitem>
<listitem>
The <code>local-directory-expression</code> attribute is now supported,
enabling the naming of local directories during retrieval based on the remote directory.
</listitem>
</itemizedlist>
</para>
<para>
For more information, see <xref linkend="ftp-outbound-gateway"/> and <xref linkend="sftp-outbound-gateway"/>.
</para>
</section>
<section id="3.0-remote-file-template">
<title>Remote File Template</title>
<para>
A new higher-level abstraction (<classname>RemoteFileTemplate</classname>) is provided over the
<interfacename>Session</interfacename> implementations used by the FTP and SFTP modules. While it is
used internally by endpoints, this abstraction can also be used programmatically and, like all
Spring <code>*Template</code> implemenations, reliably closes the underlying session while allowing
low level access to the session when needed.
</para>
<para>
For more information, see
<xref linkend="ftp-rft"/> and <xref linkend="sftp-rft"/>.
</para>
</section>
<section id="3.0-jdbc-mysql-v5_6_4">
<title>JDBC Message Store Improvements</title>
<para>
<emphasis>Spring Integration 3.0</emphasis> adds a new set of DDL
scripts for <emphasis>MySQL</emphasis> version 5.6.4 and higher.
Now <emphasis>MySQL</emphasis> supports <emphasis>fractional
seconds</emphasis> and is thus improving the FIFO ordering when
polling from a MySQL-based Message Store. For more information,
please see <xref linkend="jdbc-message-store-generic"/>.
</para>
</section>
<section id="3.0-jpa-persist-merge-collections">
<title>JPA Support: Improvements</title>
<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>.
</para>
<para>
In that case, each object returned by the
<interfacename>Iterable</interfacename> is treated as
an entity and persisted or merged using the underlying
<interfacename>EntityManager</interfacename>.
<emphasis>NULL</emphasis> values returned by the iterator are ignored.
</para>
<para>
The JPA adapters now have additional attributes to optionally 'flush' and 'clear'
entities from the associated persistence context after performing persistence operations.
</para>
<para>For more information see <xref linkend="jpa"/>.</para>
</section>
<section id="3.0-json-transformers">
<title>Jackson Support (JSON)</title>
<para>
<itemizedlist>
<listitem>
A new abstraction for JSON conversion has been introduced. Implementations for Jackson 1.x
and Jackson 2 are currently provided, with the version being determined by presence on
the classpath. Previously, only Jackson 1.x was supported.
</listitem>
<listitem>
The <classname>ObjectToJsonTransformer</classname> and <classname>JsonToObjectTransformer</classname>
now emit/consume headers containing type information.
</listitem>
</itemizedlist>
</para>
<para>
For more information, see 'JSON Transformers' in <xref linkend="transformer"/>.
</para>
</section>
<section id="3.0-http-endpointss">
<title>HTTP Endpoint Changes</title>
<para>
@@ -450,22 +271,23 @@
For more information see <xref linkend="http"/>.
</para>
</section>
<section id="3.0-amqp-mapping">
<title>AMQP Outbound Gateway Header Mapping</title>
<section id="3.0-json-transformers">
<title>Jackson Support (JSON)</title>
<para>
Previously, the &lt;int-amqp:outbound-gateway/&gt; mapped headers before invoking the message
converter, and the converter could overwrite headers such as <code>content-type</code>. The
outbound adapter maps the headers after the conversion, which means headers like
<code>content-type</code> from the outbound <code>Message</code> (if present) are used.
<itemizedlist>
<listitem>
A new abstraction for JSON conversion has been introduced. Implementations for Jackson 1.x
and Jackson 2 are currently provided, with the version being determined by presence on
the classpath. Previously, only Jackson 1.x was supported.
</listitem>
<listitem>
The <classname>ObjectToJsonTransformer</classname> and <classname>JsonToObjectTransformer</classname>
now emit/consume headers containing type information.
</listitem>
</itemizedlist>
</para>
<para>
Starting with this release, the gateway now maps the headers after the message conversion,
consistent with the adapter. If your application relies on the previous behavior (where the
converter's headers overrode the mapped headers), you either need to filter those headers
(before the message reaches the gateway)
or set them appropriately. The headers affected by the <classname>SimpleMessageConverter</classname>
are <code>content-type</code> and <code>content-encoding</code>. Custom message converters
may set other headers.
For more information, see 'JSON Transformers' in <xref linkend="transformer"/>.
</para>
</section>
<section id="3.0-id-for-chain-sub-components">
@@ -479,85 +301,145 @@
For more information see <xref linkend="chain"/>.
</para>
</section>
<section id="3.0-jms-mdca-te">
<title>JMS Message Driven Channel Adapter</title>
<section id="3.0-corr-endpoint-empty-groups">
<title>Aggregator 'empty-group-min-timeout' property</title>
<para>
Previously, when configuring a <code>&lt;message-driven-channel-adapter/&gt;</code>, if you wished to
use a specific <interfacename>TaskExecutor</interfacename>, it was necessary to declare a container
bean and provide it to the adapter using the <code>container</code> attribute. The
<code>task-executor</code> is now provided, allowing it to be set directly on the adapter. This is
in addition to several other container attributes that were already available.
The <classname>AbstractCorrelatingMessageHandler</classname> provides a new property
<code>empty-group-min-timeout</code>
to allow empty group expiry to run on a longer schedule than expiring partial groups. Empty groups will
not be removed from the <interfacename>MessageStore</interfacename> until they have not been modified
for at least this number of milliseconds. For more information see <xref linkend="aggregator-config"/>.
</para>
</section>
<section id="3.0-rmi-ec">
<title>RMI Inbound Gateway</title>
<section id="3.0-filelistfilter">
<title>Persistent File List Filters (file, (S)FTP)</title>
<para>
The RMI Inbound Gateway now supports an <code>error-channel</code> attribute. See
<xref linkend="rmi-inbound"/>.
New <classname>FileListFilter</classname>s that use a persistent <classname>MetadataStore</classname> are
now available. These can be used to prevent duplicate files after a system restart. See
<xref linkend="file-reading"/>, <xref linkend="ftp-inbound"/>, and <xref linkend="sftp-inbound"/> for more information.
</para>
</section>
<section id="3.0-stored-proc-sql-return-type">
<title>Stored Procedure Components Improvements</title>
<section id="3.0-scripting-variables">
<title>Scripting Support: Variables Changes</title>
<para>
For more complex database-specific types, not supported by the standard
<code>CallableStatement.getObject</code> method, 2 new additional
attributes were introduced to the <code>&lt;sql-parameter-definition/&gt;</code>
element with OUT-direction:
</para>
<itemizedlist>
<listitem><emphasis>type-name</emphasis></listitem>
<listitem><emphasis>return-type</emphasis></listitem>
</itemizedlist>
<para>
<para>
The <code>row-mapper</code> attribute of the Stored Procedure Inbound Channel Adapter
<code>&lt;returning-resultset/&gt;</code> sub-element
now supports a reference to a <interfacename>RowMapper</interfacename> bean
definition. Previously, it contained just a class name (which is still supported).
</para>
<para>
For more information see <xref linkend="stored-procedures"/>.
</para>
A new <code>variables</code> attribute has been introduced for scripting components.
In addition, variable bindings are now allowed for inline scripts.
See <xref linkend="groovy"/> and <xref linkend="scripting"/> for more information.
</para>
</section>
<section id="3.0-event-for-imap-idle">
<title>IMAP Idle Connection Exceptions</title>
<section id="3.0-direct-channel-lb-ref">
<title>Direct Channel Load Balancing configuration</title>
<para>
Previously, if an IMAP idle connection failed, it was logged but there was no mechanism to
inform an application. Such exceptions now generate <classname>ApplicationEvent</classname>s.
Applications can obtain these events using an <code>&lt;int-event:inbound-channel-adapter&gt;</code>
or any <interfacename>ApplicationListener</interfacename> configured to receive an
<classname>ImapIdleExceptionEvent</classname> or one of its super classes.
Previously, when configuring <classname>LoadBalancingStrategy</classname> on the channel's 'dispatcher' sub-element,
the only available option was to use a pre-defined enumeration of values which did not allow one to set a custom implementation
of the <classname>LoadBalancingStrategy</classname>. You can now use <code>load-balancer-ref</code> to provide
a reference to a custom implementation of the <classname>LoadBalancingStrategy</classname>.
For more information see <xref linkend="channel-implementations-directchannel"/>.
</para>
</section>
<section id="3.0-message-id">
<title>Message ID Generation</title>
<section id="3.0-pub-sub">
<title>PublishSubscribeChannel Behavior</title>
<para>
Previously, message ids were generated using the JDK <code>UUID.randomUUID()</code> method. With this
release, the default mechanism has been changed to use a more efficient algorithm which
is significantly faster. In addition, the ability to change
the strategy used to generate message ids has been added.
For more information see <xref linkend="message-id-generation"/>.
Previously, sending to a &lt;publish-subscribe-channel/&gt; that had
no subscribers would return a <code>false</code> result. If used in conjunction with
a <classname>MessagingTemplate</classname>, this would result in an exception being thrown.
Now, the <classname>PublishSubscribeChannel</classname> has a property
<code>minSubscribers</code> (default 0). If the message is sent to at least the minimum
number of subscribers, the send is deemed to be successful (even if zero). If an application
is expecting to get an exception under these conditions, set the minimum subscribers to at
least 1.
</para>
</section>
<section id="3.0-xslt-transformer">
<title>XsltPayloadTransformer</title>
<section id="3.0-(s)ftp-changes">
<title>FTP, SFTP and FTPS Changes</title>
<para>
You can now specify the transformer factory class name using the
<code>transformer-factory-class</code> attribute. See <xref linkend="xml-xslt-payload-transformers"/>
<emphasis role="bold">The FTP, SFTP and FTPS endpoints no longer cache sessions by default</emphasis>
</para>
</section>
<section id="3.0-tcp-headers">
<title>Message Headers and TCP</title>
<para>
The TCP connection factories now enable the configuration of a flexible mechanism to
transfer selected headers (as well as the payload) over TCP. A new
<classname>TcpMessageMapper</classname>
enables the selection of the headers, and an appropriate (de)serializer needs to be
configured to write the resulting <interfacename>Map</interfacename> to the
TCP stream. A <classname>MapJsonSerializer</classname> is provided as a convenient
mechanism to transfer headers and payload over TCP.
For more information see <xref linkend="ip-headers"/>.
The deprecated <code>cached-sessions</code> attribute has been removed from all endpoints.
Previously, the embedded caching mechanism controlled by this attribute's value didn't
provide a way to limit the size of the cache, which could
grow indefinitely. The <classname>CachingConnectionFactory</classname> was introduced in
release 2.1 and it became the preferred (and is now the only) way to cache sessions.
</para>
<para>
The <classname>CachingConnectionFactory</classname> now provides a new method
<code>resetCache()</code>. This immediately closes idle sessions and causes in-use
sessions to be closed as and when they are returned to the cache.
</para>
<para>
The <classname>DefaultSftpSessionFactory</classname> (in conjunction with a
<classname>CachingSessionFactory</classname>) now supports multiplexing channels over
a single SSH connection (SFTP Only).
</para>
<para>
<emphasis role="bold">FTP, SFTP and FTPS Inbound Adapters</emphasis>
</para>
<para>
Previously, there was no way to override the default filter used to process files retrieved
from a remote server. The <code>filter</code> attribute determines which files are retrieved
but the <classname>FileReadingMessageSource</classname> uses an
<classname>AcceptOnceFileListFilter</classname>. This means that if a new copy of a file
is retrieved, with the same name as a previously copied file, no message was sent from the
adapter.
</para>
<para>
With this release, a new attribute <code>local-filter</code> allows you to override the
default filter, for example with an <classname>AcceptAllFileListFilter</classname>, or some
other custom filter.
</para>
<para>
For users that wish the behavior of the <classname>AcceptOnceFileListFilter</classname>
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>
<emphasis role="bold">FTP, SFTP and FTPS Gateways</emphasis>
</para>
<para>
<itemizedlist>
<listitem>
The gateways now support the <emphasis role="bold">mv</emphasis> command, enabling
the renaming of remote files.
</listitem>
<listitem>
The gateways now support recursive <emphasis role="bold">ls</emphasis> and
<emphasis role="bold">mget</emphasis> commands, enabling
the retrieval of a remote file tree.
</listitem>
<listitem>
The gateways now support <emphasis role="bold">put</emphasis> and
<emphasis role="bold">mput</emphasis> commands, enabling
sending file(s) to the remote server.
</listitem>
<listitem>
The <code>local-filename-generator-expression</code> attribute is now supported,
enabling the naming of local files during retrieval. By default, the same
name as the remote file is used.
</listitem>
<listitem>
The <code>local-directory-expression</code> attribute is now supported,
enabling the naming of local directories during retrieval based on the remote directory.
</listitem>
</itemizedlist>
</para>
<para>
<emphasis role="bold">Remote File Template</emphasis>
</para>
<para>
A new higher-level abstraction (<classname>RemoteFileTemplate</classname>) is provided over the
<interfacename>Session</interfacename> implementations used by the FTP and SFTP modules. While it is
used internally by endpoints, this abstraction can also be used programmatically and, like all
Spring <code>*Template</code> implementations, reliably closes the underlying session while allowing
low level access to the session when needed.
</para>
<para>
For more information, see
<xref linkend="ftp"/> and <xref linkend="sftp"/>.
</para>
</section>
<section id="3.0-outbound-gateway-requires-reply">
@@ -593,54 +475,53 @@
set <code>requires-reply</code> to false.
</important>
</section>
<section id="3.0-dalay-expression">
<title>Delayer: delay expression</title>
<section id="3.0-amqp-mapping">
<title>AMQP Outbound Gateway Header Mapping</title>
<para>
Previously, the <code>&lt;delayer&gt;</code> provided a <code>delay-header-name</code> attribute
to determine the <emphasis>delay</emphasis> value at runtime. In complex cases it was necessary
to precede the <code>&lt;delayer&gt;</code> with a <code>&lt;header-enricher&gt;</code>.
Spring Integration 3.0 introduced the <code>expression</code> attribute and <code>expression</code>
sub-element for dynamic delay determination. The <code>delay-header-name</code> attribute is now deprecated
because the header evaluation can be specified in the <code>expression</code>. In addition,
the <code>ignore-expression-failures</code> was introduced to control the behavior when an
expression evaluation fails.
For more information see <xref linkend="delayer"/>.
Previously, the &lt;int-amqp:outbound-gateway/&gt; mapped headers before invoking the message
converter, and the converter could overwrite headers such as <code>content-type</code>. The
outbound adapter maps the headers after the conversion, which means headers like
<code>content-type</code> from the outbound <code>Message</code> (if present) are used.
</para>
<para>
Starting with this release, the gateway now maps the headers after the message conversion,
consistent with the adapter. If your application relies on the previous behavior (where the
converter's headers overrode the mapped headers), you either need to filter those headers
(before the message reaches the gateway)
or set them appropriately. The headers affected by the <classname>SimpleMessageConverter</classname>
are <code>content-type</code> and <code>content-encoding</code>. Custom message converters
may set other headers.
</para>
</section>
<section id="3.0-pub-sub">
<title>PublishSubscribeChannel Behavior</title>
<section id="3.0-stored-proc-sql-return-type">
<title>Stored Procedure Components Improvements</title>
<para>
Previously, sending to a &lt;publish-subscribe-channel/&gt; that had
no subscribers would return a <code>false</code> result. If used in conjunction with
a <classname>MessagingTemplate</classname>, this would result in an exception being thrown.
Now, the <classname>PublishSubscribeChannel</classname> has a property
<code>minSubscribers</code> (default 0). If the message is sent to at least the minimum
number of subscribers, the send is deemed to be successful (even if zero). If an application
is expecting to get an exception under these conditions, set the minimum subscribers to at
least 1.
For more complex database-specific types, not supported by the standard
<code>CallableStatement.getObject</code> method, 2 new additional
attributes were introduced to the <code>&lt;sql-parameter-definition/&gt;</code>
element with OUT-direction:
</para>
<itemizedlist>
<listitem><emphasis>type-name</emphasis></listitem>
<listitem><emphasis>return-type</emphasis></listitem>
</itemizedlist>
<para>
<para>
The <code>row-mapper</code> attribute of the Stored Procedure Inbound Channel Adapter
<code>&lt;returning-resultset/&gt;</code> sub-element
now supports a reference to a <interfacename>RowMapper</interfacename> bean
definition. Previously, it contained just a class name (which is still supported).
</para>
<para>
For more information see <xref linkend="stored-procedures"/>.
</para>
</para>
</section>
<section id="3.0-jpa-first-result">
<title>JPA Adapters: first-result attribute</title>
<section id="3.0-ws-outbound-uri-substitution">
<title>Web Service Outbound URI Configuration</title>
<para>
Retrieving gateways had no mechanism to specify the first record to be retrieved which
is a common use case. The retrieving gateways now support specifying this parameter
using a <code>first-result</code> and <code>first-result-expression</code> attributes
to the gateway definition. <xref linkend="jpa-retrieving-outbound-gateway"/>.
</para>
</section>
<section id="3.0-jpa-max-results">
<title>JPA Adapters: max-results and max-results-expression Attributes</title>
<para>
The JPA retrieving gateway and inbound adapter now have an attribute to specify the maximum
number of results in a result set as an expression. In addition, the
<code>max-results</code> attribute has been introduced to replace
<code>max-number-of-results</code>, which has been deprecated.
<code>max-results</code> and <code>max-results-expression</code>
are used to provide the maximum number of results,
or an expression to compute the maximum number of results, respectively, in the
result set.
For more information see <xref linkend="jpa"/>.
Web Service Outbound Gateway 'uri' attribute now supports <code>&lt;uri-variable/&gt;</code> substitution for all
URI-schemes supported by Spring Web Services. For more information see <xref linkend="outbound-uri"/>.
</para>
</section>
<section id="3.0-redis">
@@ -665,20 +546,137 @@
For more information, see <xref linkend="redis"/>.
</para>
</section>
<section id="3.0-filelistfilter">
<title>Persistent File List Filters (file, (S)FTP)</title>
<section id="3.0-advising-filters">
<title>Advising Filters</title>
<para>
New <classname>FileListFilter</classname>s that use a persistent <classname>MetadataStore</classname> are
now available. These can be used to prevent duplicate files after a system restart. See
<xref linkend="file-reading"/>, <xref linkend="ftp-inbound"/>, and <xref linkend="sftp-inbound"/> for more information.
Previously, when a &lt;filter/&gt; had a &lt;request-handler-advice-chain/&gt;, the discard
action was all performed within the scope of the advice chain (including any downstream flow
on the <code>discard-channel</code>). The filter element now has an attribute
<code>discard-within-advice</code> (default <code>true</code>), to allow the discard action to
be performed after the advice chain completes. See <xref linkend="advising-filters"/>.
</para>
</section>
<section id="3.0-scripting-variables">
<title>Scripting Support: Variables Changes</title>
<section id="3.0-annotation-advice">
<title>Advising Endpoints using Annotations</title>
<para>
A new <code>variables</code> attribute has been introduced for scripting components.
In addition, variable bindings are now allowed for inline scripts.
See <xref linkend="groovy"/> and <xref linkend="scripting"/> for more information.
Request Handler Advice Chains can now be configured using annotations. See
<xref linkend="advising-with-annotations"/>.
</para>
</section>
<section id="3.0-o-t-s-t">
<title>ObjectToStringTransformer Improvements</title>
<para>
This transformer now correctly transforms <code>byte[]</code> and <code>char[]</code>
payloads to <classname>String</classname>. For more information see <xref linkend="transformer"/>.
</para>
</section>
<section id="3.0-jpa-changes">
<title>JPA Support Changes</title>
<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>.
</para>
<para>
In that case, each object returned by the
<interfacename>Iterable</interfacename> is treated as
an entity and persisted or merged using the underlying
<interfacename>EntityManager</interfacename>.
<emphasis>NULL</emphasis> values returned by the iterator are ignored.
</para>
<para>
The JPA adapters now have additional attributes to optionally 'flush' and 'clear'
entities from the associated persistence context after performing persistence operations.
</para>
<para>
Retrieving gateways had no mechanism to specify the first record to be retrieved which
is a common use case. The retrieving gateways now support specifying this parameter
using a <code>first-result</code> and <code>first-result-expression</code> attributes
to the gateway definition. <xref linkend="jpa-retrieving-outbound-gateway"/>.
</para>
<para>
The JPA retrieving gateway and inbound adapter now have an attribute to specify the maximum
number of results in a result set as an expression. In addition, the
<code>max-results</code> attribute has been introduced to replace
<code>max-number-of-results</code>, which has been deprecated.
<code>max-results</code> and <code>max-results-expression</code>
are used to provide the maximum number of results,
or an expression to compute the maximum number of results, respectively, in the
result set.
</para>
<para>For more information see <xref linkend="jpa"/>.</para>
</section>
<section id="3.0-dalay-expression">
<title>Delayer: delay expression</title>
<para>
Previously, the <code>&lt;delayer&gt;</code> provided a <code>delay-header-name</code> attribute
to determine the <emphasis>delay</emphasis> value at runtime. In complex cases it was necessary
to precede the <code>&lt;delayer&gt;</code> with a <code>&lt;header-enricher&gt;</code>.
Spring Integration 3.0 introduced the <code>expression</code> attribute and <code>expression</code>
sub-element for dynamic delay determination. The <code>delay-header-name</code> attribute is now deprecated
because the header evaluation can be specified in the <code>expression</code>. In addition,
the <code>ignore-expression-failures</code> was introduced to control the behavior when an
expression evaluation fails.
For more information see <xref linkend="delayer"/>.
</para>
</section>
<section id="3.0-jdbc-mysql-v5_6_4">
<title>JDBC Message Store Improvements</title>
<para>
<emphasis>Spring Integration 3.0</emphasis> adds a new set of DDL
scripts for <emphasis>MySQL</emphasis> version 5.6.4 and higher.
Now <emphasis>MySQL</emphasis> supports <emphasis>fractional
seconds</emphasis> and is thus improving the FIFO ordering when
polling from a MySQL-based Message Store. For more information,
please see <xref linkend="jdbc-message-store-generic"/>.
</para>
</section>
<section id="3.0-event-for-imap-idle">
<title>IMAP Idle Connection Exceptions</title>
<para>
Previously, if an IMAP idle connection failed, it was logged but there was no mechanism to
inform an application. Such exceptions now generate <classname>ApplicationEvent</classname>s.
Applications can obtain these events using an <code>&lt;int-event:inbound-channel-adapter&gt;</code>
or any <interfacename>ApplicationListener</interfacename> configured to receive an
<classname>ImapIdleExceptionEvent</classname> or one of its super classes.
</para>
</section>
<section id="3.0-tcp-headers">
<title>Message Headers and TCP</title>
<para>
The TCP connection factories now enable the configuration of a flexible mechanism to
transfer selected headers (as well as the payload) over TCP. A new
<classname>TcpMessageMapper</classname>
enables the selection of the headers, and an appropriate (de)serializer needs to be
configured to write the resulting <interfacename>Map</interfacename> to the
TCP stream. A <classname>MapJsonSerializer</classname> is provided as a convenient
mechanism to transfer headers and payload over TCP.
For more information see <xref linkend="ip-headers"/>.
</para>
</section>
<section id="3.0-jms-mdca-te">
<title>JMS Message Driven Channel Adapter</title>
<para>
Previously, when configuring a <code>&lt;message-driven-channel-adapter/&gt;</code>, if you wished to
use a specific <interfacename>TaskExecutor</interfacename>, it was necessary to declare a container
bean and provide it to the adapter using the <code>container</code> attribute. The
<code>task-executor</code> is now provided, allowing it to be set directly on the adapter. This is
in addition to several other container attributes that were already available.
</para>
</section>
<section id="3.0-rmi-ec">
<title>RMI Inbound Gateway</title>
<para>
The RMI Inbound Gateway now supports an <code>error-channel</code> attribute. See
<xref linkend="rmi-inbound"/>.
</para>
</section>
<section id="3.0-xslt-transformer">
<title>XsltPayloadTransformer</title>
<para>
You can now specify the transformer factory class name using the
<code>transformer-factory-class</code> attribute. See <xref linkend="xml-xslt-payload-transformers"/>
</para>
</section>
</section>

8
src/reference/docbook/xml.xml
View File

@@ -340,12 +340,8 @@
<interfacename><ulink url="http://static.springsource.org/spring-integration/api/org/springframework/integration/transformer/Transformer.html">Transformer</ulink></interfacename>.
When configuring XML transformers as beans in Spring Integration,
you would normally configure the <emphasis>Transformer</emphasis>
in conjunction with either a
<classname><ulink url="http://static.springsource.org/spring-integration/api/org/springframework/integration/transformer/MessageTransformingChannelInterceptor.html">MessageTransformingChannelInterceptor</ulink></classname>
or a <classname><ulink url="http://static.springsource.org/spring-integration/api/org/springframework/integration/transformer/MessageTransformingHandler.html">MessageTransformingHandler</ulink></classname>.
This allows the transformer to be used as either an interceptor,
which transforms the message as it is sent or received to the
<emphasis>Channel</emphasis>, or as an <emphasis>Endpoint</emphasis>.
in conjunction with a <classname><ulink url="http://static.springsource.org/spring-integration/api/org/springframework/integration/transformer/MessageTransformingHandler.html">MessageTransformingHandler</ulink></classname>.
This allows the transformer to be used as an <emphasis>Endpoint</emphasis>.
Finally, the namespace support will be discussed, which allows for
the simple configuration of the transformers as elements in XML.
</para>