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

polishing

Browse Source
This commit is contained in:
Mark Fisher
2011-12-16 16:18:06 -05:00
parent c198351061
commit 1b7c3062a5
1 changed files with 21 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

36
docs/src/reference/docbook/message-store.xml
View File

@@ -61,29 +61,35 @@
<para>However be aware of some limitations while using persistent implementations of the <classname>MessageStore</classname>.</para>
<para>The Message data (payload and headers) is <emphasis>serialized</emphasis> and <emphasis>deserialized</emphasis>
using different serialization strategies depending on the implementation of the <classname>MessageStore</classname>.
For example: when using <classname>JdbcMessageStore</classname> by default only <classname>Serializable</classname> data is persisted.
For example, when using <classname>JdbcMessageStore</classname>, only <classname>Serializable</classname> data is persisted by default.
In this case non-Serializable headers are removed before serialization occurs.
Also be aware of the protocol specific headers that are injected by transport adapters after (e.g., FTP, HTTP, JMS etc.).
For example: <literal>&lt;http:inboubd-channel-adapter/&gt;</literal> applies all HTTP-headers into Message Headers and one of them is
<classname>ArrayList</classname> of non-Serializable <classname>org.springframework.http.MediaType</classname>.
However you are able to inject your own serialization strategy as implementation of special interfaces into <classname>MessageStore</classname> to
change behaviour of serialization and deserialization.
Also be aware of the protocol specific headers that are injected by transport adapters (e.g., FTP, HTTP, JMS etc.).
For example, <literal>&lt;http:inbound-channel-adapter/&gt;</literal> maps HTTP-headers into Message Headers and one of them is an
<classname>ArrayList</classname> of non-Serializable <classname>org.springframework.http.MediaType</classname> instances.
However you are able to inject your own implementation of the <classname>Serializer</classname> and/or
<classname>Deserializer</classname> strategy interfaces into some <classname>MessageStore</classname> implementations
(such as JdbcMessageStore) to change the behaviour of serialization and deserialization.
</para>
<para>
Special attention must be payed to the headers that represent certain types of data.
For example: if one of the headers contains an instance of some <emphasis>Spring Bean</emphasis>, upon deserialization you'll end up with the different instance of the last one,
Special attention must be paid to the headers that represent certain types of data.
For example, if one of the headers contains an instance of some <emphasis>Spring Bean</emphasis>, upon deserialization you may end
up with a different instance of that bean,
which directly affects some of the implicit headers created by the framework (e.g., REPLY_CHANNEL or ERROR_CHANNEL).
Currently they are not serializable, but even if they were the deserilized channel would not represent the expected instance.
As a workaround we suggest to remove bean-refs headers via <literal>&lt;header-filer/&gt;</literal>
before sending message to some endpoint backed by persistence <classname>MessageStore</classname>
and use channel names instead of channel instances when setting those types of headers, thus allowing it to be resolved in real time by the <classname>ChannelResolver</classname>.
Currently they are not serializable, but even if they were the deserialized channel would not represent the expected instance.
As a workaround we suggest to remove bean-ref headers via a <literal>&lt;header-filter/&gt;</literal>
before sending a message to an endpoint backed by a persistent <classname>MessageStore</classname>.
Also, we recommend using channel names instead of channel instances when setting those types of headers,
thus allowing it to be resolved in real time by the <classname>ChannelResolver</classname>.
</para>
<para>
Also avoid configuration of message-flow like this: <emphasis>gateway -&gt; queue-channel (backed by persistence Message Store) -&gt; service-activator</emphasis>.
Created on the background <emphasis>Temporary Reply Channel</emphasis> will be lost after reading from queue by service-activator poller, because it will deserialized in another thread.
Also avoid configuration of a message-flow like this:
<emphasis>gateway -&gt; queue-channel (backed by a persistent Message Store) -&gt; service-activator</emphasis>
That gateway creates a <emphasis>Temporary Reply Channel</emphasis> in the background, and it will be lost by the time the
service-activator's poller reads from the queue, because it has been deserialized by another thread on the sending side.
</para>
<para>
Nevertheless we constantly thinking about potential improvements to the framework to provide some robust default serialization strategy for messages.
Nevertheless we are constantly thinking about potential improvements to the framework, such as a way to provide some
robust default serialization strategy for messages in these cases.
</para>
</important>
</para>