From 4a0e0ff97d87d61f76766f9e9b423b8feacfbbcb Mon Sep 17 00:00:00 2001 From: markpollack Date: Tue, 4 Nov 2008 07:21:10 +0000 Subject: [PATCH] doc cleanup --- doc/reference/src/msmq.xml | 427 +++++++++++++++++++------------------ doc/reference/src/wcf.xml | 4 +- 2 files changed, 222 insertions(+), 209 deletions(-) diff --git a/doc/reference/src/msmq.xml b/doc/reference/src/msmq.xml index 2d7dc409..d711a26c 100644 --- a/doc/reference/src/msmq.xml +++ b/doc/reference/src/msmq.xml @@ -16,7 +16,12 @@ * limitations under the License. */ --> - + Message Oriented Middleware - MSMQ
@@ -46,14 +51,14 @@ reference to a particular middleware technology. Spring provides the 'adapter' classes that converts between the middleware world, in this case MSMQ, and the oo-world of your business processing. This is done through - the use of Spring's MessageListenerAdapter class - and IMessageConverters. + the use of Spring's MessageListenerAdapter class and + IMessageConverters. The namespace Spring.Messaging provides the core functionality for messaging. It contains the class MessageQueueTemplate that simplifies the use of - System.Messaging.MessageQueue by handling the lack - of thread-safety in most of + System.Messaging.MessageQueue by handling the lack of + thread-safety in most of System.Messaging.MessageQueue's methods (for example Send). A single instance of MessageQueueTemplate can be used throughout your @@ -65,11 +70,11 @@ MessageQueueTemplate class is also aware of the presence of either an 'ambient' System.Transaction's transaction or a local - System.Messaging.MessageQueueTransaction. As such - if you use MessageQueueTemplate's send and receive + System.Messaging.MessageQueueTransaction. As such if + you use MessageQueueTemplate's send and receive methods, unlike with plain use of - System.Messaging.MessageQueue, you do not need to - keep track of this information yourself and call the correct overloaded + System.Messaging.MessageQueue, you do not need to keep + track of this information yourself and call the correct overloaded System.Messaging.MessageQueue method for a specific transaction environment. When using a System.Messaging.MessageQueueTransaction this would @@ -98,13 +103,12 @@ On the sending side, it involves you learning how to use MessageQueueTemplate. In both cases you will quite likely want to take advantage of using - MessageListenerConverters so you can better - structure the translation from the System.Messaging.Message data structure - to your business objects. After the initial learning hurdle, you should - find that you will be much more productive leveraging Spring's helper - classes to write enterprise MSMQ applications than rolling your own - infrastructure. Feedback and new feature requests are always - welcome. + MessageListenerConverters so you can better structure + the translation from the System.Messaging.Message data structure to your + business objects. After the initial learning hurdle, you should find that + you will be much more productive leveraging Spring's helper classes to + write enterprise MSMQ applications than rolling your own infrastructure. + Feedback and new feature requests are always welcome. The Spring.MsmqQuickstart application located in the examples directory of the distribution shows this functionality in action. @@ -120,10 +124,10 @@ demonstrated). On the client side you create an instance of the - MessageQueueTemplate class and configure it to use - a MessageQueue. This can be done programmatically - but it is common to use dependency injection and Spring's XML - configuration file to configure your client class as shown below. + MessageQueueTemplate class and configure it to use a + MessageQueue. This can be done programmatically but it + is common to use dependency injection and Spring's XML configuration file + to configure your client class as shown below. <object id='questionTxQueue' type='Spring.Messaging.Support.MessageQueueFactoryObject, Spring.Messaging'> <property name='Path' value='.\Private$\questionTxQueue'/> @@ -143,9 +147,9 @@ The MessageQueue object is created via an instance of MessageQueueFactoryObject and the - MessageQueueTemplate refers to this factory object - by name and not by reference. The SimpleSender - class looks like this + MessageQueueTemplate refers to this factory object by + name and not by reference. The SimpleSender class looks + like this public class QuestionService : IQuestionService { @@ -163,33 +167,31 @@ } This class can be shared across multiple threads and the - MessageQueueTemplate will take care of managing - thread local access to a - System.Messaging.MessageQueue as well as any - System.Messaging.IMessageFormatter + MessageQueueTemplate will take care of managing thread + local access to a System.Messaging.MessageQueue as well + as any System.Messaging.IMessageFormatter instances. Furthermore, since this is a transactional queue (only the name gives it away), the message will be sent using a single local messaging transaction. The conversion from the string to the underling message is - managed by an instance of the IMessageConverter - class. By default an implementation that uses an + managed by an instance of the IMessageConverter class. + By default an implementation that uses an XmlMessageFormatter with a - TargetType of System.String is - used. You can configure the MessageQueueTemplate to use - other IMessageConveter implementations that do - conversions above and beyond what the 'stock' - IMessageFormatters do. See the section on - MessageConverters for more details. + TargetType of System.String is used. + You can configure the MessageQueueTemplate to use other + IMessageConveter implementations that do conversions + above and beyond what the 'stock' IMessageFormatters + do. See the section on MessageConverters for more details. On the receiving side we would like to consume the messages transactionally from the queue. Since no other database operations are being performed in our server side processing, we select the - TransactionMessageListenerContainer and configure - it to use the MessageQueueTransactionManager. The + TransactionMessageListenerContainer and configure it to + use the MessageQueueTransactionManager. The MessageQueueTransactionManager an implementation of - Spring's IPlatformTransactionManager abstraction - that provides a uniform API on top of various transaction manager + Spring's IPlatformTransactionManager abstraction that + provides a uniform API on top of various transaction manager (ADO.NET,NHibernate, MSMQ, etc). Spring's MessageQueueTransactionManager is responsible for createing, committing, and rolling back a MSMQ @@ -247,9 +249,9 @@ } That is general idea. You write the sender class using - MessageQueueTemplate and the consumer class which - does not refer to any messaging specific class. The rest is configuration - of Spring provided helper classes. + MessageQueueTemplate and the consumer class which does + not refer to any messaging specific class. The rest is configuration of + Spring provided helper classes. Note that if the HandleObject method has returned a string value a reply message would be sent to a response queue. The @@ -271,8 +273,8 @@ In the last part this 'quick tour' we will configure the message listener container to handle poison messages. This is done by creating an - instance of SendToQueueExceptionHandler and setting - the property MaxRetry to be the number of exceptions or + instance of SendToQueueExceptionHandler and setting the + property MaxRetry to be the number of exceptions or retry attempts we are willing to tolerate before taking corrective actions. In this case, the corrective action is to send the message to another queue. We can then create other message listener containers to @@ -335,10 +337,10 @@ MessageQueueTemplate's property MessageQueue. A MessageQueueTemplate is created by passing a - reference to the name of a - MessageQueueFactoryObject, you can think of it as - a friendly name for your MessagingQueue and the - recipe of how to create an instance of it. See the following section on + reference to the name of a MessageQueueFactoryObject, + you can think of it as a friendly name for your + MessagingQueue and the recipe of how to create an + instance of it. See the following section on MessageQueueFactoryObject for more information. @@ -355,14 +357,12 @@ MessageConverter. The default implementation, XmlMessageConverter, uses an XmlMessageFormatter with its - TargetType set to - System.String. Note that - System.Messaging.IMessageFormatter classes are - also not thread safe, so MessageQueueTemplate + TargetType set to System.String. + Note that System.Messaging.IMessageFormatter classes + are also not thread safe, so MessageQueueTemplate ensures that thread-local instances of - IMessageConverter are used (as they generally - wrap IMessageFormatter's that are not - thread-safe). + IMessageConverter are used (as they generally wrap + IMessageFormatter's that are not thread-safe). You can use the MessageQueueTemplate to send messages to other MessageQueues by specifying their queue 'object name', @@ -384,36 +384,56 @@ object ReceiveAndConvert(); object ReceiveAndConvert(string messageQueueObjectName); The transactional settings of the underlying overloaded - System.Messaging.MessageQueue Send method that - are used are based on the following algorithm. If the message queue is - transactional and there is an ambient - MessageQueueTransaction in thread local storage - (put there via the use of Spring's - MessageQueueTransactionManager or - TransactionalMessageListenerContainer), the - message will be sent transactionally using the - MessageQueueTransaction object in thread local - storage. This lets you group together multiple messaging operations - within the same transaction without having to explicitly pass around the - MessageQueueTransaction object. If the message - queue is transactional but there is no ambient - MessageQueueTransaction, then a single message - transaction is created on each messaging operation. - (MessageQueueTransactionType = Single). If there is an ambient - System.Transactions transaction then that transaction will be used - (MessageQueueTransactionType = Automatic). Finally, if the queue is not - transactional, then a non-transactional send - (MessageQueueTransactionType = None) is used. + System.Messaging.MessageQueue Send method that are + used are based on the following algorithm. - The delegate MessagePostProcessorDelegate - has the following signature + + + If the message queue is transactional and there is an ambient + MessageQueueTransaction in thread local storage + (put there via the use of Spring's + MessageQueueTransactionManager or + TransactionalMessageListenerContainer), the + message will be sent transactionally using the + MessageQueueTransaction object in thread local + storage. + + + This lets you group together multiple messaging operations + within the same transaction without having to explicitly pass + around the MessageQueueTransaction + object. + + + + + f the message queue is transactional but there is no ambient + MessageQueueTransaction, then a single message + transaction is created on each messaging operation. + (MessageQueueTransactionType = Single). + + + + If there is an ambient System.Transactions transaction then + that transaction will be used (MessageQueueTransactionType = + Automatic). + + + + If the queue is not transactional, then a non-transactional + send (MessageQueueTransactionType = None) is used. + + + + The delegate MessagePostProcessorDelegate has + the following signature public delegate Message MessagePostProcessorDelegate(Message message); This lets you modify the message after it has been converted from - and object to a message using the - IMessageConverter but before it is sent. This is - useful for setting Message properties (e.g. + and object to a message using the IMessageConverter + but before it is sent. This is useful for setting + Message properties (e.g. CorrelationId, AppSpecific, TimeToReachQueue). Using anonymous delegates in .NET 2.0 makes this a very succinct coding task. If you have elaborate @@ -440,12 +460,12 @@ void Send(MessageQueue messageQueue, Message message); multiple threads. This Send method is commonly used when getting the MessageQueue from the ResponseQueue property of a - Message during an asynchronous receive process. - The receive timeout of the Receive operations is set + Message during an asynchronous receive process. The + receive timeout of the Receive operations is set using the ReceiveTimeout property of MessageQueueTemplate. The default value is - MessageQueue.InfiniteTimeout (which is actually - ~3 months). + MessageQueue.InfiniteTimeout (which is actually ~3 + months). The XML configuration snippit for defining a MessageQueueTemplate is shown in the previous section and also is located in the MSMQ @@ -455,15 +475,15 @@ void Send(MessageQueue messageQueue, Message message);
MessageQueueFactoryObject - The MessageQueueFactoryObject is - responsible for creating MessageQueue instances. - You configure the factory with some basic information, namely the - constructor parameters you are familiar with already when creating a - standard MessageQueue instance, and then setting + The MessageQueueFactoryObject is responsible + for creating MessageQueue instances. You configure + the factory with some basic information, namely the constructor + parameters you are familiar with already when creating a standard + MessageQueue instance, and then setting MessageQueue properties, such a Label etc. Some - configuration tasks of a MessageQueue involve - calling methods, for example to set which properties of the message to - read. These available as properties to set on the + configuration tasks of a MessageQueue involve calling + methods, for example to set which properties of the message to read. + These available as properties to set on the MessageQueueFactoryObject. An example declarative configuration is shown below @@ -484,15 +504,14 @@ void Send(MessageQueue messageQueue, Message message); </object> Whenever an object reference is made to 'testqueue' an new - instance of the MessageQueue class is created. - This Spring's so-called 'prototype' model, which differs from - 'singleton' mode. In the singleton creation mode whenever an object - reference is made to a 'testqueue' the same - MessageQueue instance would be used. So that a - new instance can be retrieved based on need, the message listener - containers take as an argument the name of the - MessageQueueFactoryObject and not a reference. - (i.e. use of 'value' instead of 'ref' in the XML). + instance of the MessageQueue class is created. This + Spring's so-called 'prototype' model, which differs from 'singleton' + mode. In the singleton creation mode whenever an object reference is + made to a 'testqueue' the same MessageQueue instance + would be used. So that a new instance can be retrieved based on need, + the message listener containers take as an argument the name of the + MessageQueueFactoryObject and not a reference. (i.e. + use of 'value' instead of 'ref' in the XML). The MessageQueueFactoryObject class is an @@ -521,8 +540,8 @@ void Send(MessageQueue messageQueue, Message message); Receive. To isolate the creation logic of these classes, the factory - interface IMessageQueueFactory is used. The - interface is shown below + interface IMessageQueueFactory is used. The interface + is shown below public interface IMessageQueueFactory { @@ -532,21 +551,21 @@ void Send(MessageQueue messageQueue, Message message); } A provided implementation, - DefaultMessageQueueFactory will create an - instance of each class per-thread. It delegates the creation of the - MessageQueue instance to the Spring container. - The argument, messageConverterObjectName, must be the id/name of a + DefaultMessageQueueFactory will create an instance of + each class per-thread. It delegates the creation of the + MessageQueue instance to the Spring container. The + argument, messageConverterObjectName, must be the id/name of a MessageQueueFactoryObject defined in the Spring container. - DefaultMessageQueueFactory leverages - Spring's local thread storage support so it will work correctly in stand - alone and web applications. + DefaultMessageQueueFactory leverages Spring's + local thread storage support so it will work correctly in stand alone + and web applications. You can use the DefaultMessageQueueFactory independent of the rest of Spring's MSMQ support should you need only - the functionality it offers. MessageQueueTemplate - and the listener containers create an instance of + the functionality it offers. MessageQueueTemplate and + the listener containers create an instance of DefaultMessageQueueFactory by default. Should you want to share the same instance across these two classes, or provide your own custom implementation, use the property @@ -562,8 +581,8 @@ void Send(MessageQueue messageQueue, Message message); messages delivered asynchronously. This support is provided in Spring by message listener containers. A message listener container is the intermediary between an IMessageListener and a - MessageQueue. (Note, message listener containers - are conceptually different than Spring's Inversion of Control container, + MessageQueue. (Note, message listener containers are + conceptually different than Spring's Inversion of Control container, though it integrates and leverages the IoC container.) The message listener container takes care of registering to receive messages, participating in transactions, resource acquisition and release, @@ -572,17 +591,16 @@ void Send(MessageQueue messageQueue, Message message); receiving a message (and possibly responding to it), and delegate boilerplate MSMQ infrastructure concerns to the framework. - A subclass of - AbstractMessageListenerContainer is used to - receive messages from a MessageQueue. Which - subclass you pick depends on your transaction processing requirements. - The following subclasses are available in the namespace + A subclass of AbstractMessageListenerContainer + is used to receive messages from a MessageQueue. + Which subclass you pick depends on your transaction processing + requirements. The following subclasses are available in the namespace Spring.Messaging.Listener - NonTransactionalMessageListenerContainer - - does not surround the receive operation with a transaction + NonTransactionalMessageListenerContainer - + does not surround the receive operation with a transaction @@ -620,12 +638,12 @@ void Send(MessageQueue messageQueue, Message message); NonTransactionalMessageListenerContainer This container performs a Receive operation on the - MessageQueue without any transactional - settings. As such messages will not be redelivered if an exception is - thrown during message processing. Exceptions during message processing - can be handled via an implementation of the interface - IExceptionHandler. This can be set via the - property ExceptionHandler on the listener. The + MessageQueue without any transactional settings. As + such messages will not be redelivered if an exception is thrown during + message processing. Exceptions during message processing can be + handled via an implementation of the interface + IExceptionHandler. This can be set via the property + ExceptionHandler on the listener. The IExceptionHandler interface is shown below public interface IExceptionHandler @@ -634,8 +652,8 @@ void Send(MessageQueue messageQueue, Message message); } An example of configuring a - NonTransactionalMessageListenerContainer with - an IExceptionHandler is shown below + NonTransactionalMessageListenerContainer with an + IExceptionHandler is shown below <!-- Queue to receive from --> @@ -698,9 +716,8 @@ void Send(MessageQueue messageQueue, Message message); This message listener container performs receive operations within the context of local transaction. This class requires an - instance of Spring's - IPlatformTransactionManager, either - AdoPlatformTransactionManager, + instance of Spring's IPlatformTransactionManager, + either AdoPlatformTransactionManager, HibernateTransactionManager, or MessageQueueTransactionManager. @@ -709,13 +726,13 @@ void Send(MessageQueue messageQueue, Message message); MessageQueueTransaction will be started before receiving the message and used as part of the container's receive operation. As with other - IPlatformTransactionManager implementation's, - the transactional resources (in this case an instance of the - MessageQueueTransaction class) is bound to - thread local storage. MessageQueueTemplate will - look in thread-local storage and use this 'ambient' transaction if - found for its send and receive operations. The message listener is - invoked and if no exception occurs, then the + IPlatformTransactionManager implementation's, the + transactional resources (in this case an instance of the + MessageQueueTransaction class) is bound to thread + local storage. MessageQueueTemplate will look in + thread-local storage and use this 'ambient' transaction if found for + its send and receive operations. The message listener is invoked and + if no exception occurs, then the MessageQueueTransactionManager will commit the MessageQueueTransaction. @@ -726,14 +743,14 @@ void Send(MessageQueue messageQueue, Message message); TransactionalMessageListenerContainer will call it's IMessageTransactionExceptionHandler implementation to determine if the - MessageQueueTransaction should commit (removing - the message from the queue) or rollback (leaving the message on the - queue for redelivery). + MessageQueueTransaction should commit (removing the + message from the queue) or rollback (leaving the message on the queue + for redelivery). The use of a transactional service layer in combination with - a MessageQueueTransactionManager is a - powerful combination that can be used to achieve "exactly one" - transaction message processing with database operations. This - requires a little extra programming effort and is a more efficient + a MessageQueueTransactionManager is a powerful + combination that can be used to achieve "exactly one" transaction + message processing with database operations. This requires a + little extra programming effort and is a more efficient alternative than using distributed transactions which are commonly associated with this functionality since both the database and the message transaction commit or rollback together. @@ -818,18 +835,18 @@ void Send(MessageQueue messageQueue, Message message); If you specify either AdoPlatformTransactionManager or - HibernateTransactionManager then a local - database transaction will be started before the receiving the message. - By default, the container will also start a local - MessageQueueTransaction after the local - database transaction has started, but before the receiving the - message. This MessageQueueTransaction will be - used to receive the message. By default the - MessageQueueTransaction will be bound to thread - local storage so that any MessageQueueTemplate - send or receive operations will participate transparently in the same - MessageQueueTransaction. If you do not want - this behavior set the property + HibernateTransactionManager then a local database + transaction will be started before the receiving the message. By + default, the container will also start a local + MessageQueueTransaction after the local database + transaction has started, but before the receiving the message. This + MessageQueueTransaction will be used to receive the + message. By default the MessageQueueTransaction + will be bound to thread local storage so that any + MessageQueueTemplate send or receive operations + will participate transparently in the same + MessageQueueTransaction. If you do not want this + behavior set the property ExposeContainerManagedMessageQueueTransaction to false. @@ -837,17 +854,17 @@ void Send(MessageQueue messageQueue, Message message); processing when using either either AdoPlatformTransactionManager or HibernateTransactionManager the container's - IMessageTransactionExceptionHandler will - determine if the MessageQueueTransaction should - commit (removing it from the queue) or rollback (placing it back on - the queue for redelivery). The listener exception will always trigger - a rollback in the 'outer' database transaction. + IMessageTransactionExceptionHandler will determine + if the MessageQueueTransaction should commit + (removing it from the queue) or rollback (placing it back on the queue + for redelivery). The listener exception will always trigger a rollback + in the 'outer' database transaction. Poison message handing, that is, the endless redelivery of a message due to exceptions during processing, can be detected using implementations of the - IMessageTransactionExceptionHandler. This - interface is shown below + IMessageTransactionExceptionHandler. This interface + is shown below public interface IMessageTransactionExceptionHandler { @@ -858,18 +875,17 @@ void Send(MessageQueue messageQueue, Message message); Commit and Rollback. A specific implementation is provided that will move the poison message to another queue after a maximum number of redelivery attempts. See - SendToQueueExceptionHandler described below. - You can set a specific implementation to by setting - TransactionalMessageListenerContainer's - property + SendToQueueExceptionHandler described below. You + can set a specific implementation to by setting + TransactionalMessageListenerContainer's property MessageTransactionExceptionHandler The IMessageTransactionExceptionHandler - implementation SendToQueueExceptionHandler - keeps track of the Message's Id property in memory - with a count of how many times an exception has occurred. If that - count is greater than the handler's MaxRetry count - it will be sent to another queue using the provided + implementation SendToQueueExceptionHandler keeps + track of the Message's Id property in memory with a + count of how many times an exception has occurred. If that count is + greater than the handler's MaxRetry count it will + be sent to another queue using the provided MessageQueueTransaction. The queue to send the message to is specified via the property MessageQueueObjectName. @@ -894,8 +910,8 @@ void Send(MessageQueue messageQueue, Message message); Exceptions in message listener processing are handled by implementations of the - IDistributedTransactionExceptionHandler - interface. This interface is shown below + IDistributedTransactionExceptionHandler interface. + This interface is shown below public interface IDistributedTransactionExceptionHandler { @@ -933,13 +949,13 @@ void Send(MessageQueue messageQueue, Message message); Using MessageConverters In order to facilitate the sending of business model objects, the - MessageQueueTemplate has various send methods - that take a .NET object as an argument for a message's data content. The + MessageQueueTemplate has various send methods that + take a .NET object as an argument for a message's data content. The overloaded methods ConvertAndSend and ReceiveAndConvert in - MessageQueue delegate the conversion process to - an instance of the IMessageConverter - interface. This interface defines a simple contract to convert between - .NET objects and JMS messages. The interface is shown below + MessageQueue delegate the conversion process to an + instance of the IMessageConverter interface. This + interface defines a simple contract to convert between .NET objects and + JMS messages. The interface is shown below public interface IMessageConverter : ICloneable { @@ -949,8 +965,7 @@ void Send(MessageQueue messageQueue, Message message); } There are a standard implementations provided the simply wrap - existing IMessageFormatter - implementations. + existing IMessageFormatter implementations. @@ -974,9 +989,8 @@ void Send(MessageQueue messageQueue, Message message); containers is an instance of XmlMessageConverter configured with a TargetType to be System.String. You specify the types that the XmlMessageConverter can convert though either the array property - TargetTypes or - TargetTypeNames. Here is an example taken from - the QuickStart application + TargetTypes or TargetTypeNames. + Here is an example taken from the QuickStart application <object id="xmlMessageConverter" type="Spring.Messaging.Support.Converters.XmlMessageConverter, Spring.Messaging"> <property name="TargetTypes"> @@ -989,17 +1003,16 @@ void Send(MessageQueue messageQueue, Message message); </object> You can specify other IMessageConverter - implementations using the - MessageConverterObjectName property on the - MessageQueueTemplate and - MessageListenerAdapter. + implementations using the MessageConverterObjectName + property on the MessageQueueTemplate and + MessageListenerAdapter. Other implementations provided are - XmlDocumentConverter - loads and saves - an XmlDocument to the message BodyStream. This lets you manipulate + XmlDocumentConverter - loads and saves an + XmlDocument to the message BodyStream. This lets you manipulate directly the XML data independent of type serialization issues. This is quite useful if you use XPath expressions to pick out the relevant information to construct your business objects. @@ -1038,15 +1051,15 @@ void Send(MessageQueue messageQueue, Message message);
MessageListenerAdapater - The MessageListenerAdapter allows methods - of a class that does not implement the + The MessageListenerAdapter allows methods of + a class that does not implement the IMessageListener interface to be invoked upon message delivery. Lets call this class the 'message handler' class. To achieve this goal the MessageListenerAdapter - implements the standard IMessageListener - interface to receive a message and then delegates the processing to - the message handler class. Since the message handler class does not - contain methods that refer to MSMQ artifacts such as Message, the + implements the standard IMessageListener interface + to receive a message and then delegates the processing to the message + handler class. Since the message handler class does not contain + methods that refer to MSMQ artifacts such as Message, the MessageListenerAdapter uses a IMessageConverter to bridge the MSMQ and 'plain object' worlds. As a reminder, the default @@ -1103,11 +1116,11 @@ void Send(MessageQueue messageQueue, Message message); then be sent to the ResponseQueue defined in the Message's ResponseQueue property of the original Message, or the DefaultResponseQueueName on the - MessageListenerAdapter (if one has been - configured) will be used. If not ResponseQueue is - found then an Spring MessagingException will be - thrown. Please note that this exception will not be swallowed and will - propagate up the call stack. + MessageListenerAdapter (if one has been configured) + will be used. If not ResponseQueue is found then an + Spring MessagingException will be thrown. Please + note that this exception will not be swallowed and will propagate up + the call stack. Here is an example of Handler signatures that have various return types. @@ -1121,8 +1134,8 @@ void Send(MessageQueue messageQueue, Message message); } The following configuration shows how to hook up the adapter to - process incoming MSMQ messages using the default message converter. - + process incoming MSMQ messages using the default message + converter. <!-- Delegate to plain .NET object for message handling --> <object id="messageListenerAdapter" type="Spring.Messaging.Listener.MessageListenerAdapter, Spring.Messaging"> @@ -1164,4 +1177,4 @@ void Send(MessageQueue messageQueue, Message message);
- \ No newline at end of file + diff --git a/doc/reference/src/wcf.xml b/doc/reference/src/wcf.xml index eff105dd..4a46fa0e 100644 --- a/doc/reference/src/wcf.xml +++ b/doc/reference/src/wcf.xml @@ -246,7 +246,7 @@ attributes that get applied to each method and on that class. Here is a simple example - <object id="HelloWorldExporter" type="Spring.ServiceModel.ServiceExporter, Spring.Services"> + <object id="HelloWorldExporter" type="Spring.ServiceModel.ServiceExporter, Spring.Services"> <property name="TargetName" value="HelloWorld"/> <property name="MemberAttributes"> <dictionary> @@ -271,6 +271,6 @@ existing RCP based approach, such as using .NET remoting, to WCF in order to take advantage of the WCF runtime and avoid editing much existing code. You can then incrementally refactor and/or create new operations that use - DataContractSerializer. + DataContractSerializer.