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

INT-676

Browse Source
This commit is contained in:
Mark Fisher
2009-07-04 02:06:21 +00:00
parent b416eca31e
commit 4ffe311816
2 changed files with 39 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

47
spring-integration-reference/src/samples.xml
View File

@@ -1,15 +1,18 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
<appendix id="samples">
<title>Spring Integration Samples</title>
<para>
Starting with the current release of Spring Integration the <emphasis>samples</emphasis> are distributed as independent Maven-based projects
(<ulink url="http://maven.apache.org/">http://maven.apache.org/</ulink>) to minimize the setup time.
Since each project is also an Eclipse-based project, they could be imported as is using "Import existing project wizard".
If you prefer other IDE, configuration should be very trivial, since a special Maven profile was setup to download all the
required dependencies required by all samples.
Detailed instructions on how to run samples provided in README file located in the <emphasis>samples</emphasis> directory of the main distribution.
</para>
<note>
Starting with the current release of Spring Integration the <emphasis>samples</emphasis> are distributed as independent
Maven-based projects (<ulink url="http://maven.apache.org/">http://maven.apache.org/</ulink>) to minimize the setup time.
Since each project is also an Eclipse-based project, they can be imported as is using "Import existing project wizard".
If you prefer another IDE, configuration should be very trivial, since a special Maven profile was setup to download all
of the required dependencies for all samples. Detailed instructions on how to build and run the samples are provided in
the <code>README.txt</code> file located in the <emphasis>samples</emphasis> directory of the main distribution.
</note>
<section id="samples-cafe">
<title>The Cafe Sample</title>
<para>
@@ -31,7 +34,7 @@
The <classname>Order</classname> object may contain multiple <classname>OrderItems</classname>. Once the order
is placed, a <emphasis>Splitter</emphasis> will break the composite order message into a single message per
drink. Each of these is then processed by a <emphasis>Router</emphasis> that determines whether the drink is hot
or cold (checking the <classname>OrderItem</classname> object's 'isIced' property). Finally the
or cold (checking the <classname>OrderItem</classname> object's 'isIced' property). The
<classname>Barista</classname> prepares each drink, but hot and cold drink preparation are handled by two
distinct methods: 'prepareHotDrink' and 'prepareColdDrink'. The prepared drinks are then sent to the Waiter where
they are aggregated into a <classname>Delivery</classname> object.
@@ -195,16 +198,10 @@
}
}]]></programlisting>
</para>
<para>
To run this demo, go to the "samples" directory within the root of the Spring Integration distribution. On
Unix/Mac you can run 'cafeDemo.sh', and on Windows you can run 'cafeDemo.bat'. Each of these will by default
create a Spring <interfacename>ApplicationContext</interfacename> from the 'cafeDemo.xml' file that is
in the "spring-integration-samples" JAR and hence on the classpath (it is the same as the XML above). However, a
copy of that file is also available within the "samples" directory, so that you can provide the file name as a
command line argument to either 'cafeDemo.sh' or 'cafeDemo.bat'. This will allow you to experiment with the
configuration and immediately run the demo with your changes. It is probably a good idea to first copy the
original file so that you can make as many changes as you want and still refer back to the original to compare.
</para>
<tip>
To run this sample as well as 8 others, refer to the <code>README.txt</code> within the "samples" directory
of the main distribution as described at the beginning of this chapter.
</tip>
<para>
When you run cafeDemo, you will see that the cold drinks are initially prepared more quickly than the hot drinks.
Because there is an aggregator, the cold drinks are effectively limited by the rate of the hot drink preparation.
@@ -233,17 +230,16 @@
then you will notice that occasionally it throttles the input by forcing the task-scheduler (the caller) to invoke
the operation.
</para>
<para>
<note>
In addition to experimenting with the poller's concurrency settings, you can also add the 'transactional'
sub-element. If you want to explore the sample in more detail, the source JAR is available in the "src"
directory: 'org.springframework.integration.samples-sources-1.0.0.jar'.
</para>
sub-element and then refer to any PlatformTransactionManager instance within the context.
</note>
</section>
<section id="samples-xml-messaging">
<title>The xml messaging sample</title>
<para>
The xml messaging sample in <package>org.springframework.integration.samples.xml</package> illustrates how to use
The xml messaging sample in the <package>org.springframework.integration.samples.xml</package> illustrates how to use
some of the provided components which deal with xml payloads. The sample uses the idea of processing an order for books
represented as xml.
</para>
@@ -284,7 +280,6 @@
xsl-resource="classpath:org/springframework/integration/samples/xml/bigBooksSupplierTransformer.xsl"/>
]]></programlisting>
</para>
</section>
</section>
</appendix>

32
spring-integration-reference/src/service-activator.xml
View File

@@ -34,33 +34,37 @@
"output-channel" was provided in the endpoint configuration:
<programlisting language="xml">&lt;service-activator input-channel="exampleChannel" output-channel="replyChannel"
ref="somePojo" method="someMethod"/&gt;</programlisting>
If no "output-channel" is available, it will then check the Message's <literal>RETURN_ADDRESS</literal> header
If no "output-channel" is available, it will then check the Message's <literal>REPLY_CHANNEL</literal> header
value. If that value is available, it will then check its type. If it is a
<interfacename>MessageChannel</interfacename>, the reply message will be sent to that channel. If it is a
<classname>String</classname>, then the endpoint will attempt to resolve the channel name to a channel instance.
If the channel cannot be resolved, then a <classname>ChannelResolutionException</classname> will be thrown.
</para>
<para>
The argument in the service method could be either a Message or an arbitrary type. If the later one, then it will be assumed that it is a Payload source,
which will be extracted from the message and injected into such service method. This is generally the recommended approach as it follows and promotes
a POJO model when working with Spring Integration.
Since v1.0.3 of Spring Integration, the service method does not require to have an argument at all, which means you can now implement event-style Service Activators,
where all you care about is an invocation of the service method not worrying about the contents of the message. Think of it as a NULL JMS message. An example use-case for such implementation
could be a simple counter/monitor of messages deposited on the input channel.
The argument in the service method could be either a Message or an arbitrary type. If the latter, then it will
be assumed that it is a Message payload, which will be extracted from the message and injected into such service
method. This is generally the recommended approach as it follows and promotes a POJO model when working with Spring
Integration. Arguments may also have @Header or @Headers annotations as described in <xref linkend="annotations"/>
</para>
<note>
Since v1.0.3 of Spring Integration, the service method is not required to have an argument at all, which means you
can now implement event-style Service Activators, where all you care about is an invocation of the service method,
not worrying about the contents of the message. Think of it as a NULL JMS message. An example use-case for such an
implementation could be a simple counter/monitor of messages deposited on the input channel.
</note>
<para>
Using a "ref" attribute is generally recommended if custom Service Activator handler implementation can be reused in other <code>&lt;service-activator&gt;</code> definitions. However
if custom Service Activator handler implementation has to be scoped to a concrete definition of the <code>&lt;service-activator&gt;</code>, starting with v1.0.3, Spring Integration supports
inner bean definitions for custom Service Activator handlers within the <code>&lt;service-activator&gt;</code> element:
<programlisting language="xml"><![CDATA[<service-activator id="testServiceActivator" input-channel="inChannel"
Using a "ref" attribute is generally recommended if the custom Service Activator handler implementation can be reused
in other <code>&lt;service-activator&gt;</code> definitions. However if the custom Service Activator handler implementation
should be scoped to a single definition of the <code>&lt;service-activator&gt;</code>, you can use an inner bean definition:
<programlisting language="xml"><![CDATA[<service-activator id="exampleServiceActivator" input-channel="inChannel"
output-channel = "outChannel" method="foo">
<beans:bean class="org.foo.TestServiceActivator" /> \
<beans:bean class="org.foo.ExampleServiceActivator"/>
</service-activator>]]></programlisting>
</para>
<note>
<para>
Using both "ref" attribute and inner handler definition in the same <code>&lt;service-activator&gt;</code> configuration
is not allowed, as it creates an ambiguous condition and will result in Exception being thrown
Using both the "ref" attribute and an inner handler definition in the same <code>&lt;service-activator&gt;</code>
configuration is not allowed, as it creates an ambiguous condition and will result in an Exception being thrown.
</para>
</note>
</section>