Updating reference documentation for M2.

spring-integration-reference/reference/src/adapters.xml

@@ -9,8 +9,8 @@
       are external to the messaging system. As the name implies, the interaction consists of adapting the external
       system or component to send-to and/or receive-from a <interfacename>MessageChannel</interfacename>. Within
       Spring Integration, there is a distinction between <emphasis>source adapters</emphasis> and <emphasis>target
-      adapters</emphasis>. In the 1.0 Milestone 1 release, Spring Integration includes adapters for JMS, Files,
+      adapters</emphasis>. In the 1.0 Milestone 2 release, Spring Integration includes source and target adapters
-      Streams, and Spring ApplicationEvents.
+      for JMS, Files, Streams, and Spring ApplicationEvents as well as a target adapter for sending e-mail.
     </para>
   </section>
 
@@ -60,8 +60,9 @@
       The <classname>JmsTargetAdapter</classname> is a <interfacename>MessageHandler</interfacename> implementation
       that is capable of mapping Spring Integration <interfacename>Messages</interfacename> to JMS messages and then
       sending to a JMS destination. It requires either a 'jmsTemplate' reference or both 'connectionFactory' and
-      'destination' references. In <xref linkend="namespace-adapters"/>, you will see how to configure a JMS target
+      'destination' references (again, the 'destinationName' may be provided in place of the 'destination). In
-      adapter with Spring Integration's namespace support.
+      <xref linkend="namespace-adapters"/>, you will see how to configure a JMS target adapter with Spring
+      Integration's namespace support.
     </para>
   </section>
   <section id="adapters-file">
@@ -117,8 +118,8 @@
       To send Spring <classname>ApplicationEvents</classname>, register an instance of the
       <classname>ApplicationEventTargetAdapter</classname> class as the handler of an endpoint (such configuration
       will be described in detail in <xref linkend="namespace-endpoint"/>). This adapter implements Spring's
-      <interfacename>ApplicationEventPublisherAware</interfacename> and thus acts as a bridge between Spring
+      <interfacename>ApplicationEventPublisherAware</interfacename> interface and thus acts as a bridge between
-      Integration <classname>Messages</classname> and <classname>ApplicationEvents</classname>.
+      Spring Integration <classname>Messages</classname> and <classname>ApplicationEvents</classname>.
     </para>
   </section>
 </chapter>

spring-integration-reference/reference/src/configuration.xml

@@ -88,6 +88,28 @@
                        should-fail-on-rejection-limit="false"/>
 </channel>]]></programlisting>
       </para>
+      <para>
+        To create a <ulink url="http://www.eaipatterns.com/DatatypeChannel.html">Datatype Channel</ulink> that only
+        accepts messages containing a certain payload type, provide the fully-qualified class name in the
+        channel element's <literal>datatype</literal> attribute:
+        <programlisting><![CDATA[<channel id="numberChannel" datatype="java.lang.Number"/>]]></programlisting>
+        Note that the type check passes for any type that is <emphasis>assignable</emphasis> to the channel's
+        datatype. In other words, the "numberChannel" above would accept messages whose payload is
+        <classname>java.lang.Integer</classname> or <classname>java.lang.Double</classname>. Multiple types can be
+        provided as a comma-delimited list:
+        <programlisting><![CDATA[<channel id="stringOrNumberChannel" datatype="java.lang.String,java.lang.Number"/>]]></programlisting> 
+      </para>
+      <para>
+        Message channels may also have interceptors as described in <xref linkend="api-channelinterceptor"/>. One or
+        more &lt;interceptor&gt; elements can be added as sub-elements of &lt;channel&gt;. Provide the "ref" attribute
+        to reference any Spring-managed object that implements the <interfacename>ChannelInterceptor</interfacename>
+        interface:
+        <programlisting><![CDATA[<channel id="exampleChannel">
+    <interceptor ref="trafficMonitoringInterceptor"/>
+</channel>]]></programlisting>
+        In general, it is a good idea to define the interceptors in a separate location since they usually provide
+        common behavior that can be reused across multiple channels.
+      </para>
     </section>
 
     <section id="namespace-endpoint">

spring-integration-reference/reference/src/core-api.xml

@@ -128,6 +128,45 @@ new GenericMessage&lt;T&gt;(T payload, MessageHeader headerToCopy)</programlisti
     </para>
   </section>
 
+  <section id="api-channelinterceptor">
+    <title>ChannelInterceptor</title>
+    <para>
+      One of the advantages of a messaging architecture is the ability to provide common behavior and capture
+      meaningful information about the messages passing through the system in a non-invasive way. Since the
+      <interfacename>Messages</interfacename> are being sent to and received from
+      <interfacename>MessageChannels</interfacename>, those channels provide an opportunity for intercepting
+      the send and receive operations. The <interfacename>ChannelInterceptor</interfacename> strategy interface
+      provides methods for each of those operations:
+      <programlisting><![CDATA[public interface ChannelInterceptor {
+    boolean preSend(Message<?> message, MessageChannel channel);
+    void postSend(Message<?> message, MessageChannel channel, boolean sent);
+    boolean preReceive(MessageChannel channel);
+    void postReceive(Message<?> message, MessageChannel channel);
+}]]></programlisting>
+      After implementing the interface, registering the interceptor with a channel is just a matter of calling:
+      <programlisting>channel.addInterceptor(someChannelInterceptor);</programlisting>
+      The methods that return a <literal>boolean</literal> value can return '<literal>false</literal>' to prevent the
+      send or receive operation from proceeding (send would return 'false' and receive would return 'null').
+    </para>
+    <para>
+      Because it is rarely necessary to implement all of the interceptor methods, a
+      <classname>ChannelInterceptorAdapter</classname> class is also available for sub-classing. It provides no-op
+      methods (the <literal>void</literal> methods are empty, and the <literal>boolean</literal> methods return
+      <literal>true</literal>). Therefore, it is often easiest to extend that class and just implement the method(s)
+      that you need as in the following example.
+      <programlisting><![CDATA[public class CountingChannelInterceptor extends ChannelInterceptorAdapter {
+
+    private final AtomicInteger sendCount = new AtomicInteger();
+
+    @Override
+    public boolean preSend(Message<?> message, MessageChannel channel) {
+        sendCount.incrementAndGet();
+        return true;
+    }
+}]]></programlisting>
+    </para>
+  </section>
+
   <section id="api-messagehandler">
     <title>MessageHandler</title>
     <para>