From 608ada3c5c87c3f05a77dafa82dc0173b54941eb Mon Sep 17 00:00:00 2001 From: Mark Fisher Date: Mon, 22 Nov 2010 12:10:35 -0500 Subject: [PATCH] INT-1552 doc polishing --- .../reference/docbook/content-enrichment.xml | 77 +++++++++++-------- docs/src/reference/docbook/control-bus.xml | 25 +++--- 2 files changed, 57 insertions(+), 45 deletions(-) diff --git a/docs/src/reference/docbook/content-enrichment.xml b/docs/src/reference/docbook/content-enrichment.xml index b9b363327e..9223183b64 100644 --- a/docs/src/reference/docbook/content-enrichment.xml +++ b/docs/src/reference/docbook/content-enrichment.xml @@ -6,8 +6,8 @@
Introduction - Some time you may have a requirement to enhance a request with more information then it was - provided by the target system. Content Enricher pattern + At times you may have a requirement to enhance a request with more information than was + provided by the target system. The Content Enricher pattern describes various scenarios as well as the component (Enricher), which allows you to address such requirements.
@@ -17,8 +17,9 @@ If you only need to add headers to a Message, and they are not dynamically determined by the Message content, - then referencing a custom implementation of the Transformer may be an overkill. For that reason, - Spring Integration provides the Header Enricher which is exposed via <header-enricher> element. + then referencing a custom implementation of a Transformer may be overkill. For that reason, + Spring Integration provides support for the Header Enricher pattern. It is exposed via + the <header-enricher> element. @@ -27,7 +28,7 @@ - Header Enricher also provides helpful sub-elements to set well known header names. + The Header Enricher also provides helpful sub-elements to set well-known header names. @@ -36,52 +37,60 @@ ]]> - In the above configuration you can clearly see that for well known headers such as errorChannel, - correlationId, priority, replyChanneletc., instead of using generic <header> - sub-element where you would have to provide both header 'name' and 'value', you can use convenient sub-elements - allowing you to set those values directly. + In the above configuration you can clearly see that for well-known headers such as errorChannel, + correlationId, priority, replyChanneletc., instead of using generic + <header> sub-elements where you would have to provide both header 'name' and 'value', + you can use convenient sub-elements to set those values directly. + + + POJO Support + + + Often a header value cannot be defined statically and has to be determined dynamically based on some content in the Message. That is why + Header Enricher allows you to also specify a bean 'ref' and 'method' that will calculate the + header value. Let's look at the following configuration: + + + + + +]]> + + + + SpEL Support - In Spring Integration 2.0 we are introducing convenience of + In Spring Integration 2.0 we have introduced the convenience of the Spring Expression Language (SpEL) - to help configure many different components. Header Enricher is one of them. - A lot of times, header value cannot be defined statically and has to be computed dynamically. That is why - Header Enricher allows you to also specify bean 'ref' and 'method' that will calculate the - header value. Let's look at the following configuration: - - - - - -]]> + to help configure many different components. The Header Enricher is one of them. - + Looking again at the POJO example above, you can see that the computation logic to determine the header value is actually pretty simple. + A natural question would be: "is there a simpler way to accomplish this?". That is where SpEL shows its true power. - As you can see that the computation logic to determine the header value is actually pretty simple and the - natural question would be is there a simpler way to accomplish this? And that is where SpEL shows its true power. - ]]> - As you can see, with SpEL for simple cases like above we no longer have to provide a separate class and configure - it in the application context. All we need is to use expression attribute and provide a valid - SpEL expression. You can also see that 'payload' and 'headers' are bound as variables to the SpEL Evaluation Context + As you can see, by using SpEL for such simple cases, we no longer have to provide a separate class and configure + it in the application context. All we need is the expression attribute configured with a valid + SpEL expression. The 'payload' and 'headers' variables are bound to the SpEL Evaluation Context, giving you full access to the incoming Message. - + Adapter specific Header Enrichers - As you go through the manual you will see that as an added convenience - Spring Integration provides adapter specific Header Enrichers (e.g., MAIL, XMPP, etc.) + As you go through the manual, you will see that as an added convenience, + Spring Integration also provides adapter specific Header Enrichers (e.g., MAIL, XMPP, etc.) diff --git a/docs/src/reference/docbook/control-bus.xml b/docs/src/reference/docbook/control-bus.xml index a59fd2fea8..4aecefdb34 100644 --- a/docs/src/reference/docbook/control-bus.xml +++ b/docs/src/reference/docbook/control-bus.xml @@ -25,21 +25,24 @@ The Control Bus executes messages on the input channel as Spring Expression Language expressions. It takes a message, compiles the body to an expression, adds some context, and then executes it. The default context - just exposes all the beans in the application context by name with the usual - SpEL prefix for beans (@). So to execute a method on a Spring Bean a client - would send a message to the operation channel: + supports any method that has been annotated with @ManagedAttribute or @ManagedOperation. + It also supports the methods on Spring's Lifecycle interface, and it supports methods + that are used to configure several of Spring's TaskExecutor and TaskScheduler implementations. + The simplest way to ensure that your own methods are available to the Control Bus is to + use the @ManagedAttribute and/or @ManagedOperation annotations. Since those are also used + for exposing methods to a JMX MBean registry, it's a convenient by-product (often the same + types of operations you want to expose to the Control Bus would be reasonable for exposing + via JMS). Resolution of any particular instance within the application context is achieved + in the typical SpEL syntax. Simply provide the bean name with the SpEL prefix for beans (@). + For example, to execute a method on a Spring Bean a client + could send a message to the operation channel as follows: Message operation = MessageBuilder.withPayload("@myServiceBean.shutdown()"); operationChannel.send(operation) The root of the context for the expression is the - Message itself, so you also have access to the body - and headers, the same as all the other expressions in Spring Integration - endpoints. + Message itself, so you also have access to the 'payload' + and 'headers' as variables within your expression. This is consistent with all the other expression + support in Spring Integration endpoints. - The execution context for the expressions can be customized by - providing a BeanResolver instance: - - <control-bus input-channel="operationChannel" bean-resolver="beanResolver"/> -<beans:bean class="com.mycompany.MyCustomBeanResolver"/>