JavaConfig/DSL Docs for Routers (Part 1)

Also fix DSL messing `sendTimeout` property for routers.
Since other message handlers have this property on the `ConsumerEndpointSpec`, add support there
instead of `RouterSpec`, for consistency.
Also fix `ConsumerEndpointSpec` `sendTimeout` - can be applied to any
`AbstractMessageProducingHandler`, not just `AbstractReplyProducingMessageHandler`.
Ditto for `async`.

Polishing

src/reference/asciidoc/router.adoc

@@ -589,6 +589,55 @@ The example below demonstrates a `PayloadTypeRouter` configuration which is equi
 </int:payload-type-router>
 ----
 
+The equivalent router, using Java configuration:
+
+[source, java]
+----
+@ServiceActivator(inputChannel = "routingChannel")
+@Bean
+public PayloadTypeRouter router() {
+    PayloadTypeRouter router = new PayloadTypeRouter();
+    router.setChannelMapping(String.class.getName(), "stringChannel");
+    router.setChannelMapping(Integer.class.getName(), "integerChannel");
+    return router;
+}
+----
+
+When using the Java DSL, there are two options; 1) define the router object as above...
+
+[source, java]
+----
+@Bean
+public IntegrationFlow routerFlow1() {
+    return IntegrationFlows.from("routingChannel")
+            .route(router())
+            .get();
+}
+
+public PayloadTypeRouter router() {
+    PayloadTypeRouter router = new PayloadTypeRouter();
+    router.setChannelMapping(String.class.getName(), "stringChannel");
+    router.setChannelMapping(Integer.class.getName(), "integerChannel");
+    return router;
+}
+----
+
+Note that the router can be, but doesn't have to be, a `@Bean` - the flow will register it if it is not.
+
+2) define the routing function within the DSL flow itself...
+
+[source, java]
+----
+@Bean
+public IntegrationFlow routerFlow2() {
+    return IntegrationFlows.from("routingChannel")
+            .<Object, Class<?>>route(Object::getClass, m -> m
+                    .channelMapping(String.class, "stringChannel")
+                    .channelMapping(Integer.class, "integerChannel"))
+            .get();
+}
+----
+
 [[router-implementations-headervaluerouter]]
 ===== HeaderValueRouter
 
@@ -627,6 +676,56 @@ However, in cases where the header value is mapped to a channel name but the cha
 IMPORTANT: With Spring Integration 2.1 the attribute was changed from `ignore-channel-name-resolution-failures` to `resolution-required`.
 Attribute `resolution-required` will default to `true`.
 
+The equivalent router, using Java configuration:
+
+[source, java]
+----
+@ServiceActivator(inputChannel = "routingChannel")
+@Bean
+public HeaderValueRouter router() {
+    HeaderValueRouter router = new HeaderValueRouter("testHeader");
+    router.setChannelMapping("someHeaderValue", "channelA");
+    router.setChannelMapping("someOtherHeaderValue", "channelB");
+    return router;
+}
+----
+
+When using the Java DSL, there are two options; 1) define the router object as above...
+
+[source, java]
+----
+@Bean
+public IntegrationFlow routerFlow1() {
+    return IntegrationFlows.from("routingChannel")
+            .route(router())
+            .get();
+}
+
+public HeaderValueRouter router() {
+    HeaderValueRouter router = new HeaderValueRouter("testHeader");
+    router.setChannelMapping("someHeaderValue", "channelA");
+    router.setChannelMapping("someOtherHeaderValue", "channelB");
+    return router;
+}
+----
+
+Note that the router can be, but doesn't have to be, a `@Bean` - the flow will register it if it is not.
+
+2) define the routing function within the DSL flow itself...
+
+[source, java]
+----
+@Bean
+public IntegrationFlow routerFlow2() {
+    return IntegrationFlows.from("routingChannel")
+            .<Message<?>, String>route(m -> m.getHeaders().get("testHeader", String.class), m -> m
+                    .channelMapping("someHeaderValue", "channelA")
+                    .channelMapping("someOtherHeaderValue", "channelB"),
+                e -> e.id("headerValueRouter"))
+            .get();
+}
+----
+
 _2.
 Configuration where mapping of header values to channel names
               is not required since header values themselves represent channel names_
@@ -676,8 +775,45 @@ Spring Integration also provides namespace support for the `RecipientListRouter`
 </int:recipient-list-router>
 ----
 
+The equivalent router, using Java configuration:
+
+[source, java]
+----
+@ServiceActivator(inputChannel = "routingChannel")
+@Bean
+public RecipientListRouter router() {
+    RecipientListRouter router = new RecipientListRouter();
+    router.setSendTimeout(1_234L);
+    router.setIgnoreSendFailures(true);
+    router.setApplySequence(true);
+    router.addRecipient("channel1");
+    router.addRecipient("channel2");
+    router.addRecipient("channel3");
+    return router;
+}
+----
+
+The equivalent router, using the Java DSL:
+
+[source, java]
+----
+@Bean
+public IntegrationFlow routerFlow() {
+    return IntegrationFlows.from("routingChannel")
+            .routeToRecipients(r -> r
+                    .applySequence(true)
+                    .ignoreSendFailures(true)
+                    .recipient("channel1")
+                    .recipient("channel2")
+                    .recipient("channel3"), c -> c.sendTimeout(1_234L))
+            .get();
+}
+----
+
+
+
 NOTE: The 'apply-sequence' flag here has the same effect as it does for a publish-subscribe-channel, and like a publish-subscribe-channel, it is disabled by default on the recipient-list-router.
-Refer to<<channel-configuration-pubsubchannel>> for more information.
+Refer to <<channel-configuration-pubsubchannel>> for more information.
 
 Another convenient option when configuring a `RecipientListRouter` is to use Spring Expression Language (SpEL) support as selectors for individual recipient channels.
 This is similar to using a Filter at the beginning of 'chain' to act as a "Selective Consumer".