标签：resource 其他 call tps 可重复 live 平衡 另一个 数据库访问
最后部分的XML懒得写了，因为个人更倾向于JavaConfig形式。
为知笔记版本见这里，带格式~
做了一个小demo，放到码云上了，有兴趣的点我。
说明：需要先了解下JMS的基础知识。
Spring 提供了一个JMS集成框架，简化了JMS API的使用，类似于Spring提供的JDBC API集成。
JMS可以粗略地划分成两大功能区域，就是消息的生产(production)和消费(consumption)。JmsTemplate 用于消息的生产和同步的消息接收。对于异步消息接收，类似于Java EE的消息驱动，Spring提供了大量了message listener container，可以用于创建Message-Driven POJOs (MDPs)。Spring还提供了一种声明式创建消息监听器的方式。
JmsTemplate是JMS core package的中心类。它简化了JMS的使用，因为它负责处理资源的创建和释放 -- 当发送、同步接收消息时。
使用JmsTemplate的代码，只需要实现回调接口。MessageCreator回调接口负责创建一个消息，使用的是JmsTemplate提供的Session。为了允许更复杂的JMS API使用，回调SessionCallback 提供了JMS session，而ProducerCallback则暴露了Session、MessageProducer pair。
JMS API 暴露了两种类型的send方法，一种使用投递模式、优先级、TTL作为Quality of Service (QOS)参数，一种不携带QOS参数 -- 使用默认值。由于JmsTemplate中有很多send方法，QOS参数的设置已经被暴露为bean properties，以避免让send方法的数量翻倍。类似地，用于同步接收调用的timeout值也是通过setReceiveTimeout设置的。
一些JMS providers允许通过ConnectionFactory的配置来设置QOS的默认值。这会有影响，当调用 MessageProducer’s send method `send(Destination destination, Message message) 时，会使用不同的QOS默认值，而非在JMS spec中指定的值。为了提供一致的QOS管理，JmsTemplate 必须特别地启用它自己的QOS值 -- 通过将 isExplicitQosEnabled设为 true。
为了方便，JmsTemplate还暴露了一个基础的 请求-应答 操作，允许发送一个消息，然后等待一个响应 -- 在该操作创建的一个临时的queue上。
注意：一旦配置完成，JmsTemplate的实例都是线程安全的。这非常重要，因为这意味着你可以配置一个唯一的JmsTemplate实例，然后将其安全地注入到多个bean中。要清楚，JmsTemplate是带状态的，它维持了一个对ConnectionFactory的引用，但该状态不是一个对话状态（双向状态）。
自Spring Framework 4.1起，JmsMessagingTemplate 构建于JmsTemplate之上，提供了消息抽象的集成，例如 org.springframework.messaging.Message。 这允许你以泛泛的方式创建消息来发送。
JmsTemplate 要求引用一个ConnectionFactory。ConnectionFactory 是JMS spec的一部分，作为JMS的入口。客户端应用会使用它来创建连接 -- 其实现由JMS provider提供，并封装不同的配置参数，许多参数都是供应商特定的，例如SSL配置选项。
当在EJB中使用JMS时，供应商提供了JMS接口的实现，因此，它们可以参与声明式事务管理，可以执行连接和session的池化。为了使用这种实现，Java EE containers 通常要求用户声明一个JMS连接工厂作为EJB或servlet部署描述符中的 resource-ref。为了确保EJB中JmsTemplate对这些功能的使用，客户端应用应该确保它引用了被管理的ConnectionFactory实现。
缓存的消息资源
标准API 涉及到了很多中间件对象的创建。想要发送一条消息，会执行下面的API步骤：
ConnectionFactory->Connection->Session->MessageProducer->send
这ConnectionFactory和Send操作之间，创建和销毁了三个中间件对象。我们提供了两个ConnectionFactory的实现，以优化资源的使用和释放。
SingleConnectionFactory
该实现，会在所有的createConnection()调用时返回相同的Connection，并忽略close()的调用。这在测试环境和独立运行环境中很有用，因为多次JmsTemplate的调用都会使用同一个连接，方便事务管理。
该实现，需要引用标准的ConnectionFactory（通常来自JNDI）。
CachingConnectionFactory
该实现继承了SingleConnectionFactory，并添加了Session、MessageProducer、MessageConsumer的缓存。默认的缓存数量是1，可以使用property sessionCacheSize修改。
注意：实际缓存的sessions数量会多于那个值，这是因为session的缓存是基于它们的应答模式（acknowledgment mode），所以，最多可能四倍的数量。
MessageProducer和MessageConsumer会缓存在各自的session中。
MessageProducer是基于它们的destination而缓存的。MessageConsumer是基于一个key而缓存的，该key由destination、selector、noLocal delivery flag、以及durable subscription name（如果创建了durable consumers的话）组成。
类似于ConnectionFactories，Destinations也是JMS管理的对象，也可以被存储，可以通过JNDI获取。
在配置一个Spring的application context的时候，你可以使用JNDI工厂类 JndiObjectFactoryBean / <jee:jndi-lookup> 来执行依赖注入，注入到对JMS destinations引用的对象中。然而，经常，这种策略是冗长的 -- 如果有大量的destinations 或者有不同于JMS provider的高级destination管理特性。这种高级destination管理的例子，可能是动态destinations的创建 或者 对于destinations层级命名空间的支持。
JmsTemplate使用DestinationResolver接口的实现来代理了destination名字到JMS destination对象的解析。
JmsTemplate默认使用的实现是DynamicDestinationResolver，负责解析动态的destinations。
还提供了JndiDestinationResolver，作为包含在JNDI中的destinations的一个service locator，并能可选地会滚到DynamicDestinationResolver的行为。
很常见的一种情况是，JMS应用中的destinations仅在运行时才知道，因此，无法在应用部署时创建。这很常见是因为 在交互式系统组件之间有一种共享的应用逻辑，就是在运行时按照一种众所周知的命名惯例来创建destinations。即使动态destinations的创建不是JMS spec的一部分，大多数提供商仍然提供了这种功能。动态destinations是使用用户定义的名字创建的，这使得它们与临时的destinations不同，且经常不在JNDI中注册。创建动态destinations的API随着提供商的不同而不同，因为关键到destination的properties通常都是提供商特有的。However, a simple implementation choice that is sometimes made by vendors is to disregard the warnings in the JMS specification and to use the TopicSession method createTopic(String topicName) or the QueueSession method createQueue(String queueName) to create a new destination with default destination properties. Depending on the vendor implementation, DynamicDestinationResolver may then also create a physical destination instead of only resolving one.
JmsTemplate的boolean property pubSubDomain 被用于配置使用什么样的JMS domain。其默认值是false，表明是一个p2p domain，会使用Queues。JmsTemplate使用该property来决定动态destination解析的行为 -- 通过DestinationResolver接口的实现。
你还可以为JmsTemplate配置一个默认的destination -- 通过property defaultDestination。当不指定destination时，就会使用这个默认的destination来发送和接收。
在EJB世界中 JMS消息的最常见用法的一种是，驱动 消息驱动的beans（drive message-driven beans MDBs）。Spring提供了一种解决方案来创建message-driven POJOs (MDPs)，不需要将用户绑定到EJB容器。（见4.2、异步接收 - MDPs）。自Spring Framework 4.1起，可以使用@JmsListener来注解端点方法，详见6、注解驱动的监听器端点。
消息监听器容器是被用于接收来自JMS消息队列的消息，并驱动注入其中的MessageListener。该监听器容器负责所有的消息接收线程，并分发到监听器处理。消息监听器容器，是MDP和消息提供者之间的中间件，负责注册接收消息、参与事务、资源获取和释放、异常转换等等。这可以让你作为一个应用开发者专注业务逻辑。
Spring提供了两种标准JMS消息监听器容器，每种都有其独特的特色集。
SimpleMessageListenerContainer
该消息监听器容器是两种标准flavors的简化版。它会在启动时创建固定数量的JMS sessions和consumers，使用标准的JMS MessageConsumer.setMessageListener()方法注册监听器，并由JMS提供者来执行监听器回调。该变体不允许动态适配运行时需求，不允许参与外部被管理的事务。
在兼容性方面，非常类似于独立的JMS spec，但一般不兼容Java EE的JMS限制。
注意：虽然不允许参与外部被管理的事务，但支持native JMS事务：将sessionTransacted设为true即可，或者在namespace中将acknowledge设为transacted，此时，你的监听器抛出的异常都会导致回滚，消息会重新投递。
或者，考虑使用‘CLIENT_ACKNOWLEDGE‘ mode，也会在异常时重新投递，但不使用transacted Sessions，因此，没有包含任何其他Session操作（例如发出响应消息） -- 以事务协议。
DefaultMessageListenerContainer
该消息监听器容器可以用于大多数场景。不同于SimpleMessageListenerContainer，该容器变体允许动态适配运行时需求，且参与外部被管理的事务。
接收到的每个消息，都会被注册一个XA事务 -- 当配置了JtaTransactionManager时；因此，其处理可能利用XA事务语义。
该消息监听器容器试图在降低对JMS provider的要求、高级功能（如参与外部的被管理的事务）和Java EE环境的兼容性之间做出一个平衡。
该容器的缓存级别可以自定义。注意，当不启用缓存时，每次消息接收都会创建新的connection和session。当与高负载下的非持久化订阅结合时，可能会导致消息的丢失。务必使用一个恰当的缓存级别。
当broker挂掉时，该容器也具备恢复能力。默认，一个简单的BackOff实现会每隔5秒重试一次。也可以指定一个自定义的BackOff实现，例子可以参考ExponentialBackOff。
注意：和SimpleMessageListenerContainer类似，DefaultMessageListenerContainer也支持native JMS事务，还允许自定义应答模式。（略）
Spring提供了JmsTransactionManager，负责管理单一JMS ConnectionFactory的事务。它允许JMS应用利用Spring的事务管理特性。
JmsTransactionManager执行本地资源事务，从指定的ConnectionFactory到线程 绑定一个JMS Connection/Session pair。
JmsTemplate自动侦测该事务性的资源，并操作它们。
在一个JavaEE环境中，ConnectionFactory会池化Connections和Sessions，因此，资源会在事务之间被复用。在独立环境中，使用Spring的SingleConnectionFactory 会导致一个共享的JMS Connection，每个事务都有其独立的Session。或者，考虑使用provider-specific pooling adapter，如ActiveMQ的PooledConnectionFactory。
JmsTemplate也可以使用JtaTransactionManager 和 XA-capable JMS ConnectionFactory 来执行分布式事务。注意，这要求使用JTA事务管理器 以及 合适的XA-configured ConnectionFactory！（详见Java EE server / JMS provider 的文档。）
当使用JMS API来从一个Connection创建一个Session时，在被管理和未被管理的事务性环境中 复用代码 可能混淆。 这是因为JMS API只有一个工厂方法来创建Session，它要求设置事务和应答模式。在一个被管理的环境中，这些值的设置是环境的事务性设施来负责的，因此 这些值会被供应商的JMS Connection封装所忽略。当在未被管理的环境中使用JmsTemplate时，你可以通过使用properties sessionTransacted和sessionAcknowledgeMod来指定这些值。当配合PlatformTransactionManager时，JmsTemplate会总是使用一个事务性的JMS Session。
JmsTemplate 包含了很多便利方法 来发送消息。有需要使用Destination对象来指定destination的方法，也有使用String来指定destination的方法。那些没有指定destination的方法，会使用默认的destination。
import javax.jms.ConnectionFactory;import javax.jms.JMSException;import javax.jms.Message;import javax.jms.Queue;import javax.jms.Session;import org.springframework.jms.core.MessageCreator;import org.springframework.jms.core.JmsTemplate;public class JmsQueueSender { private JmsTemplate jmsTemplate; private Queue queue; public void setConnectionFactory(ConnectionFactory cf) { this.jmsTemplate = new JmsTemplate(cf); } public void setQueue(Queue queue) { this.queue = queue; } public void simpleSend() { this.jmsTemplate.send(this.queue, new MessageCreator() { public Message createMessage(Session session) throws JMSException { return session.createTextMessage("hello queue world"); } }); }}该例子使用 MessageCreator 回调来创建一个text message -- 使用提供的Session对象。JmsTemplate的构造需要传入一个ConnectionFactory的引用。或者，无参构造，然后设置connectionFactory。或者，考虑从Spring的JmsGatewaySupport 便捷基类中中获取，会提供一个预先构建好JMS配置的bean properties。
方法 send(String destinationName, MessageCreator creator) 可以让你发送一条消息。其destination是字符串形式的，如果是在JNDI中注册的， 那你应该将template的destinationResolver property设为JndiDestinationResolver。
如果你创建了JmsTemplate，并指定了默认的destination，方法send(MessageCreator c) 会直接发送到那个destination。
为了能够发送domain model objects，JmsTemplate有不同的发送方法 接受一个Java对象作为参数 -- 作为消息的内容。
重载方法convertAndSend()和receiveAndConvert() 将这种转换处理代理到MessageConverter接口的实例。该接口定义了一个简单的约定来转换Java对象和JMS消息。
默认的实现是SimpleMessageConverter，支持String和TextMessage、byte[]和BytesMessage、java.util.Map和MapMessage之间的转换。
使用该转换器，你和你的代码可以专注于业务对象。
sandbox 目前包含一个MapMessageConverter，它使用反射来进行JavaBean和MapMessage之间的转换。其他流行的实现包括JAXB、Castor、XMLBeans、XStream，来创建一个TextMessage。
为了容纳消息的properties、headers以及body的设置 （不能通用地封装进一个转换器类中），MessagePostProcessor接口允许在转换之后、发送之前访问该消息。下面的例子演示了如何修改一个消息的header和一个property -- 在java.util.Map被转成消息之后。
public void sendWithConversion() { Map map = new HashMap(); map.put("Name", "Mark"); map.put("Age", new Integer(47)); jmsTemplate.convertAndSend("testQueue", map, new MessagePostProcessor() { public Message postProcessMessage(Message message) throws JMSException { message.setIntProperty("AccountID", 1234); message.setJMSCorrelationID("123-00001"); return message; } });}其结果是这样的：
MapMessage={ Header={ ... standard headers ... CorrelationID={123-00001} } Properties={ AccountID={Integer:1234} } Fields={ Name={String:Mark} Age={Integer:47} }}有一些情况下，你可能想要在一个JMS Session或MessageProducer上执行多个操作。SessionCallback 和 ProducerCallback 暴露了JMS Session 和 Session / MessageProducer pair。JmsTemplate的execute() 方法会执行这些回调。
JMS通常关联到异步处理，但也可以进行同步处理。
重载方法receive(..) 提供这种功能。在一个同步接收中，调用的线程会阻塞住，直到获取了消息。这是一种很危险的操作，因为调用的线程可能永久卡住。property receiveTimeout 可以指定接收器等待多久，而不必一直卡住。
Spring 还提供了注解式监听器端点 -- 使用@JmsListener。目前为止，这是最便捷的方式来设置一个异步接收器，详见6.2、启用监听器端点注解。
类似于EJB世界里的Message-Driven Bean，Message-Driven POJO扮演了JMS消息的接收器。MDP的一个限制是，它必须实现javax.jms.MessageListener接口 （看一下下面MessageListenerAdapter的讨论）。请注意，POJO在多线程上接收消息时，必须确保你的实现是线程安全的。
下面是MDP的一个简单实现：
import javax.jms.JMSException;import javax.jms.Message;import javax.jms.MessageListener;import javax.jms.TextMessage;public class ExampleListener implements MessageListener { public void onMessage(Message message) { if (message instanceof TextMessage) { try { System.out.println(((TextMessage) message).getText()); } catch (JMSException ex) { throw new RuntimeException(ex); } } else { throw new IllegalArgumentException("Message must be of type TextMessage"); } }}当你实现了你的MessageListener，就可以创建一个消息监听器容器了。
下面的例子演示了如何定义和配置一个消息监听器容器（Spring提供的，该例子用的是DefaultMessageListenerContainer）。
<!-- this is the Message Driven POJO (MDP) --><bean id="messageListener" class="jmsexample.ExampleListener" /><!-- and this is the message listener container --><bean id="jmsContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer"> <property name="connectionFactory" ref="connectionFactory"/> <property name="destination" ref="destination"/> <property name="messageListener" ref="messageListener" /></bean>详情请查阅不同的消息监听器容器的javadocs。
该接口是Spring专有的接口，提供了类似于JMS MessageListener接口的约定，还提供了消息处理方法 -- 通过访问接收Message的JMS Session。
package org.springframework.jms.listener;public interface SessionAwareMessageListener { void onMessage(Message message, Session session) throws JMSException;}你可以选择让你的MDPs实现该接口（也可以偏好JMS MessageListener） -- 如果你想你的MDPs能够响应任何接收到的消息（使用这里提供的Session）。
请注意：这里的onMessage(..)方法抛出了JMSException。而标准的JMS MessageListener则需要用户自己处理异常。
该类是Spring的异步消息支持的最终组件：简言之，它允许你将几乎任意类暴露为MDP（当然，有一些限制）。
看看下面的接口定义。注意，虽然该接口既没有继承MessageListener，也没有继承SessionAwareMessageListener，它仍然可以被用作一个MDP -- 通过使用MessageListenerAdapter类。
public interface MessageDelegate { void handleMessage(String message); void handleMessage(Map message); void handleMessage(byte[] message); void handleMessage(Serializable message);}public class DefaultMessageDelegate implements MessageDelegate { // implementation elided for clarity...}特别的，注意上面的实现，没有任何JMS依赖！通过下面的配置，我们可以将其制作成一个MDP！！！
<!-- this is the Message Driven POJO (MDP) --><bean id="messageListener" class="org.springframework.jms.listener.adapter.MessageListenerAdapter"> <constructor-arg> <bean class="jmsexample.DefaultMessageDelegate"/> </constructor-arg></bean><!-- and this is the message listener container... --><bean id="jmsContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer"> <property name="connectionFactory" ref="connectionFactory"/> <property name="destination" ref="destination"/> <property name="messageListener" ref="messageListener" /></bean>下面是另一个MDP例子，只能处理JMS TextMessage。注意，实际调用的消息处理方法是 receive （而MessageListenerAdapter的默认方法名字是handleMessage），但可以配置（下面有说）。注意，receive(..)方法仅能响应JMS TextMessage消息。
public interface TextMessageDelegate { void receive(TextMessage message);}public class DefaultTextMessageDelegate implements TextMessageDelegate { // implementation elided for clarity...}相应的MessageListenerAdapter的配置如下：
<bean id="messageListener" class="org.springframework.jms.listener.adapter.MessageListenerAdapter"> <constructor-arg> <bean class="jmsexample.DefaultTextMessageDelegate"/> </constructor-arg> <property name="defaultListenerMethod" value="receive"/> <!-- we don‘t want automatic message context extraction --> <property name="messageConverter"> <null/> </property></bean>注意，上面的messageListener 如果接收了一个JMS类型，而非TextMessage类型，会抛出IllegalStateException。该异常会被消化！！
MessageListenerAdapter的另一个能力就是能够自动发回一个响应Message -- 如果一个处理器方法返回了non-void值。看看下面的接口和类：
public interface ResponsiveTextMessageDelegate { // notice the return type... String receive(TextMessage message);}public class DefaultResponsiveTextMessageDelegate implements ResponsiveTextMessageDelegate { // implementation elided for clarity...}如果上面的 DefaultResponsiveTextMessageDelegate 配合 MessageListenerAdapter 使用，然后receive(..)返回的所有的non-null值 都会（默认配置）被转成TextMessage。该TextMessage会被发送至 在源Message中定义的JMS Reply-To property Destination（如果存在），或者发送至 MessageListenerAdapter中设置的默认Destination；如果没有找到Destination，那么会抛出InvalidDestinationException （请注意，该异常不会被消化，而是会传播到上一层调用栈）。
在一个事务中调用消息监听器，只需要重新配置下监听器容器。
通过设置监听器容器的sessionTransacted，可以很轻松地激活本地资源事务。每个消息监听器调用都会在一个活动的JMS事务中操作，监听器执行失败时 会回滚消息异常。
通过SessionAwareMessageListener发送一个响应消息，也是同一个本地事务的一部分，但任何其他资源操作（如数据库访问）则会独立地操作。这一般要求在监听器实现中进行重复的消息侦测，需要涵盖 数据库处理已提交 但消息处理提交失败的情况。
<bean id="jmsContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer"> <property name="connectionFactory" ref="connectionFactory"/> <property name="destination" ref="destination"/> <property name="messageListener" ref="messageListener"/> <property name="sessionTransacted" value="true"/></bean>为了参与进外部被管理的事务中，你需要配置一个事务管理器，并使用支持外部被管理的事务的监听器容器，通常是 DefaultMessageListenerContainer。
为了配置一个消息监听器容器 使用XA 事务参与，需要配置一个JtaTransactionManager （默认，其会代理到Java EE server的事务子系统中）。注意，底层的JMS ConnectionFactory需要是XA-capable的，并正确地注册到你的JTA事务坐标系中。（详见你的Java EE server的JNDI资源配置）。这允许消息接收 以及数据库访问 成为同一个事务的一部分（统一的提交语义，耗费的是XA事务日志overhead）。
<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"/>然后，你只需要将其添加到我们之前的容器配置中即可。该容器会负责剩下的部分：
<bean id="jmsContainer" class="org.springframework.jms.listener.DefaultMessageListenerContainer"> <property name="connectionFactory" ref="connectionFactory"/> <property name="destination" ref="destination"/> <property name="messageListener" ref="messageListener"/> <property name="transactionManager" ref="transactionManager"/></bean>自版本2.5开始，Spring还提供了对于基于JCA的MessageListener容器的支持。
>>>>>>>>>>>>>>>>>>略<<<<<<<<<<<<<<<<<<<
异步接收消息 的最简单的方式 是使用注解式监听器端点。简言之，它允许你将一个被管理的bean的方法暴露成一个JMS监听器端点。
@Componentpublic class MyService { @JmsListener(destination = "myDestination") public void processOrder(String data) { ... }}上面的例子就是，只要在 javax.jms.Destination "destination"上有可用的消息时，就会调用该processOrder 方法（这种情况下，JMS消息的内容类似于MessageListenerAdapter提供的）。
该注解式端点设施，在幕后 为每一个被注解的方法 创建了一个消息监听器容器 -- 通过使用JmsListenerContainerFactory。该容器没有注册在application context中，但是，通过使用JmsListenerEndpointRegistry bean，可以容易地定位该容器 以便管理。
注意：在Java 8中，@JmsListener 是一个可重复的注解，就是说，可以关联多个JMS destinations到同一个方法中。而在Java 6和7中，你可以使用@JmsListeners 注解。
为了启用注解@JmsListener，你需要在你的一个@Configuration类上添加注解@EnableJms。
@Configuration@EnableJmspublic class AppConfig { @Bean public DefaultJmsListenerContainerFactory jmsListenerContainerFactory() { DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory(); factory.setConnectionFactory(connectionFactory()); factory.setDestinationResolver(destinationResolver()); factory.setConcurrency("3-10"); return factory; }}默认，该infrastructure 会查找名字为jmsListenerContainerFactory 的bean，将其作为factory的源 来创建消息监听器容器。 在上面的例子中，忽略掉JMS infrastructure 的设置，processOrder方法会调用3个初始线程、最多10个池线程。
也可以自定义监听器容器工厂，按照每个注解来使用，或者配置一个显式的默认--通过实现JmsListenerConfigurer 接口。如果至少一个端点没有被配置特定的容器工厂，那就会需要该默认。
详见javadoc和下面的例子。
如果你倾向于使用XML配置，请使用<jms:annotation-driven> 元素。
<jms:annotation-driven/><bean id="jmsListenerContainerFactory" class="org.springframework.jms.config.DefaultJmsListenerContainerFactory"> <property name="connectionFactory" ref="connectionFactory"/> <property name="destinationResolver" ref="destinationResolver"/> <property name="concurrency" value="3-10"/></bean>JmsListenerEndpoint 提供一个JMS端点的model，并负责为该model配置容器。除了通过注解JmsListener配置之外，infrastructure 还允许你编码式配置端点。
@Configuration@EnableJmspublic class AppConfig implements JmsListenerConfigurer { @Override public void configureJmsListeners(JmsListenerEndpointRegistrar registrar) { SimpleJmsListenerEndpoint endpoint = new SimpleJmsListenerEndpoint(); endpoint.setId("myJmsEndpoint"); endpoint.setDestination("anotherQueue"); endpoint.setMessageListener(message -> { // processing }); registrar.registerEndpoint(endpoint); }}在上面的例子中，我们使用了SimpleJmsListenerEndpoint，它负责提供实际的MessageListener，你也可以构建你自己的端点变体。
注意，你还可以不使用@JmsListener，完全使用JmsListenerConfigurer 编码式注册你的端点。
到目前为止，我们已经在我们的端点中注入了一个简单的String，但它实际上还可以有更灵活的方法签名。让我们来重写一下，注入Order和自定义header：
@Componentpublic class MyService { @JmsListener(destination = "myDestination") public void processOrder(Order order, @Header("order_type") String orderType) { ... }}你可以注入到JMS监听器端点的主要元素包括：
原生的javax.jms.Message 或其任意子类（当然需要匹配来信类型）。
javax.jms.Session 以可选的访问native JMS API，如发生一个自定义的应答。
org.springframework.messaging.Message 代表了incoming JMS消息。注意，该消息持有自定义的和标准的headers（如JmsHeaders所定义的）。
@Header 注解的参数，必须能够赋给 java.util.Map以访问所有headers。
一个无注解的元素，且不是被支持的类型（如Message 和 Session），被认为是payload（内容？）。你可以使用注解@Payload来显式地声明。你还可以打开校验，通过再添加一个@Valid。
注入Spring的Message abstraction的能力特别重要 -- 可以利用所有存储在特定传输中的消息的所有信息，而不需要使用特定传输的API来应答。
@JmsListener(destination = "myDestination")public void processOrder(Message<Order> order) { ... }方法签名的处理，是由DefaultMessageHandlerMethodFactory 提供的，DefaultMessageHandlerMethodFactory还可以进一步定制以支持更多的方法参数。还可以同时定制转换和校验。
例如，如果我们想确认我们的Order 是有效的（在处理它之前），我们可以使用@Valid 注解，并配置必要的校验器，如下：
@Configuration@EnableJmspublic class AppConfig implements JmsListenerConfigurer { @Override public void configureJmsListeners(JmsListenerEndpointRegistrar registrar) { registrar.setMessageHandlerMethodFactory(myJmsHandlerMethodFactory()); } @Bean public DefaultMessageHandlerMethodFactory myHandlerMethodFactory() { DefaultMessageHandlerMethodFactory factory = new DefaultMessageHandlerMethodFactory(); factory.setValidator(myValidator()); return factory; }}在MessageListenerAdapter中已有的支持 允许你的方法拥有一个non-void返回类型。这种情况下，该返回值会被封装进一个javax.jms.Message 中，发送到源message的JMSReplyTo header中指定的destination，或者发送到监听器配置的默认destination。该默认destination 现在也可以在消息抽象上使用@SendTo 注解来设置。
假定我们的方法processOrder 应该返回一个OrderStatus，我们可以用下面的方式让其自动发送一个响应：
@JmsListener(destination = "myDestination")@SendTo("status")public OrderStatus processOrder(Order order) { // order processing return status;}注意：如果你有几个@JmsListener 注解的方法，你还可以将@SendTo 放在类级别上，以共用一个默认的应答destination。
如果你需要独立于传输之外设置额外的headers，那你应该返回Message，如下：
@JmsListener(destination = "myDestination")@SendTo("status")public Message<OrderStatus> processOrder(Order order) { // order processing return MessageBuilder .withPayload(status) .setHeader("code", 1234) .build();}如果你需要在运行时计算响应destination，你可以把你的响应封装进JmsResponse，它提供了运行时可用的destination。前面的例子可以重写如下：
@JmsListener(destination = "myDestination")public JmsResponse<Message<OrderStatus>> processOrder(Order order) { // order processing Message<OrderStatus> response = MessageBuilder .withPayload(status) .setHeader("code", 1234) .build(); return JmsResponse.forQueue(response, "status");}Spring提供了XML namespace以简化JMS的配置。想要使用该JMS namespace elements，你需要引用JMS schema：
<?xml version="1.0" encoding="UTF-8"?><beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jms="http://www.springframework.org/schema/jms" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/jms http://www.springframework.org/schema/jms/spring-jms.xsd"> <!-- bean definitions here --></beans>该namespace由三个顶级的elements构成：<annotation-driven/>、 <listener-container/> 和<jca-listener-container/>。第一个，启用了注解驱动的监听器端点。后两个定义了共享的监听器容器配置，可能包含<listener/> 子元素。下面是一个简单的例子：
<jms:listener-container> <jms:listener destination="queue.orders" ref="orderService" method="placeOrder"/> <jms:listener destination="queue.confirmations" ref="confirmationLogger" method="log"/></jms:listener-container>上面的例子，等效于创建两个不同的监听器容器bean定义 和 两个不同的MessageListenerAdapter bean定义 -- 如4.4章节所述。除了以上attributes，listener元素还可以包含几个可选项：
Table 30.1. Attributes of the JMS <listener> element
>>>>>>>>>>>>>>>>后面的部分略，因为个人更喜欢JavaConfig形式<<<<<<<<<<<<<<<<<
官方文档地址：
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/jms.html
标签：resource 其他 call tps 可重复 live 平衡 另一个 数据库访问
原文地址：http://www.cnblogs.com/larryzeal/p/7294564.html
