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

INT-1552 doc polishing

Browse Source
This commit is contained in:
Mark Fisher
2010-11-22 12:10:35 -05:00
parent 5c7375a3c2
commit 608ada3c5c
2 changed files with 57 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files

77
docs/src/reference/docbook/content-enrichment.xml
View File

@@ -6,8 +6,8 @@
<section id="content-enricher-introduction">
<title>Introduction</title>
<para>
Some time you may have a requirement to enhance a request with more information then it was
provided by the target system. <link href="http://www.eaipatterns.com/DataEnricher.html">Content Enricher</link> pattern
At times you may have a requirement to enhance a request with more information than was
provided by the target system. The <link href="http://www.eaipatterns.com/DataEnricher.html">Content Enricher</link> pattern
describes various scenarios as well as the component (Enricher), which allows you to address such requirements.
</para>
</section>
@@ -17,8 +17,9 @@
<para>
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 <emphasis>Header Enricher</emphasis> which is exposed via <code>&lt;header-enricher&gt;</code> element.
then referencing a custom implementation of a Transformer may be overkill. For that reason,
Spring Integration provides support for the <emphasis>Header Enricher</emphasis> pattern. It is exposed via
the <code>&lt;header-enricher&gt;</code> element.
<programlisting language="xml"><![CDATA[<int:header-enricher input-channel="in" output-channel="out">
<int:header name="foo" value="123"/>
@@ -27,7 +28,7 @@
</para>
<para>
<emphasis>Header Enricher</emphasis> also provides helpful sub-elements to set well known header names.
The <emphasis>Header Enricher</emphasis> also provides helpful sub-elements to set well-known header names.
<programlisting language="xml"><![CDATA[<int:header-enricher input-channel="in" output-channel="out">
<int:error-channel ref="applicationErrorChannel"/>
<int:reply-channel ref="quoteReplyChannel"/>
@@ -36,52 +37,60 @@
<int:header name="bar" ref="someBean"/>
</int:header-enricher>]]></programlisting>
In the above configuration you can clearly see that for well known headers such as <code>errorChannel</code>,
<code>correlationId</code>, <code>priority</code>, <code>replyChannel</code>etc., instead of using generic <emphasis>&lt;header&gt;</emphasis>
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 <code>errorChannel</code>,
<code>correlationId</code>, <code>priority</code>, <code>replyChannel</code>etc., instead of using generic
<emphasis>&lt;header&gt;</emphasis> sub-elements where you would have to provide both header 'name' and 'value',
you can use convenient sub-elements to set those values directly.
</para>
<para>
<emphasis>POJO Support</emphasis>
</para>
<para>
Often a header value cannot be defined statically and has to be determined dynamically based on some content in the Message. That is why
<emphasis>Header Enricher</emphasis> allows you to also specify a bean 'ref' and 'method' that will calculate the
header value. Let's look at the following configuration:
<programlisting language="xml"><![CDATA[<int:header-enricher input-channel="in" output-channel="out">
<int:header name="foo" method="computeValue" ref="myBean"/>
</int:header-enricher>
<bean id="myBean" class="foo.bar.MyBean"/>]]></programlisting>
<programlisting language="java"><![CDATA[public class MyBean {
public String computeValue(String payload){
return payload.toUpperCase() + "_US";
}
}]]></programlisting>
</para>
<para>
<emphasis>SpEL Support</emphasis>
</para>
<para>
In Spring Integration 2.0 we are introducing convenience of
In Spring Integration 2.0 we have introduced the convenience of the
<link href="http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/expressions.html">Spring Expression Language (SpEL)</link>
to help configure many different components. <emphasis>Header Enricher</emphasis> is one of them.
A lot of times, header value cannot be defined statically and has to be computed dynamically. That is why
<emphasis>Header Enricher</emphasis> allows you to also specify bean 'ref' and 'method' that will calculate the
header value. Let's look at the following configuration:
<programlisting language="xml"><![CDATA[<int:header-enricher input-channel="in" output-channel="out">
<int:header name="foo" method="computeValue" ref="myBean"/>
</int:header-enricher>
<bean id="myBean" class="foo.bar.MyBean"/>]]></programlisting>
to help configure many different components. The <emphasis>Header Enricher</emphasis> is one of them.
<programlisting language="java"><![CDATA[public class MyBean{
public String computeValue(String payload){
return payload.toUpperCase() + "_US";
}
}]]></programlisting>
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.
<programlisting language="xml"><![CDATA[<int:header-enricher input-channel="in" output-channel="out">
<int:header name="foo" expression="payload.toUpperCase() + '_US'"/>
</int:header-enricher>]]></programlisting>
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 <emphasis>expression</emphasis> 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 <emphasis>expression</emphasis> 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.
</para>
</para>
<para>
<emphasis>Adapter specific Header Enrichers</emphasis>
</para>
<para>
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.)
</para>
</section>

25
docs/src/reference/docbook/control-bus.xml
View File

@@ -25,21 +25,24 @@
<para>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:</para>
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:</para>
<programlisting>Message operation = MessageBuilder.withPayload("@myServiceBean.shutdown()");
operationChannel.send(operation)</programlisting>
<para>The root of the context for the expression is the
<classname>Message</classname> itself, so you also have access to the body
and headers, the same as all the other expressions in Spring Integration
endpoints.</para>
<classname>Message</classname> 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.</para>
<para>The execution context for the expressions can be customized by
providing a <classname>BeanResolver</classname> instance:</para>
<programlisting language="xml">&lt;control-bus input-channel="operationChannel" bean-resolver="beanResolver"/&gt;
&lt;beans:bean class="com.mycompany.MyCustomBeanResolver"/&gt;</programlisting>
</section>