- 浏览: 631348 次
- 性别:
- 来自: 成都
文章分类
最新评论
-
hsluoyz:
现在新推出了一个权限框架,叫jCasbin(https://g ...
Shiro 权限框架使用总结 -
飕飕飞:
比如说 我用私匙加密一段数据,并加密成功。那签名时用什么生成的 ...
Java使用RSA加密解密签名及校验 -
文艺吧网:
楼主讲的好详细,这里有整套 Shiro demo http:/ ...
Shiro 权限框架使用总结 -
nanshanmu:
333引用[url][*]||||[/flash][/flas ...
SpringMVC中返回值处理 -
变脸小伙:
) 业务类在Spring配置 ...
整合Struts2与Spring以及spring的自动装配
spring jms _ activemq
- 博客分类:
- SSH
参考链接:
http://bsnyderblog.blogspot.com/2010/02/using-spring-jmstemplate-to-send-jms.html
http://bsnyderblog.blogspot.com/2010/02/using-spring-to-receive-jms-messages.html
Recently I stumbled upon a number of places in the some docs and mailing lists where claims are made that the Spring JmsTemplate is full of anti-patterns, is horribly inefficient and shouldn't be used. Well I'm here to debunk these erroneous claims by pointing out a class in the Spring Framework that was overlooked entirely.
The Spring JmsTemplate is a convenience class for sending and receiving JMS messages in a synchronous manner. The JmsTemplate was originally designed to be used with a J2EE container where the container provides the necessary pooling of the JMS resources (i.e., connections, consumers and producers). Such requirements came from the EJB spec. But when developers began using the JmsTemplate outside of J2EE containers, and because some JMS providers do not offer caching/pooling of JMS resources, a different solution was necessary. Enter the Spring CachingConnectionFactory.
The CachingConnectionFactory is meant to wrap a JMS provider's connection to provide caching of sessions, connections and producers as well as automatic connection recovery. By default, it uses a single session to create many connections and this model works very well with most MOMs. But if you need to scale further, you can also specify the number of sessions to cache using the sessionCacheSize property.
Below is a snippet from a Spring app context that demonstrates the configuration for the CachingConnectionFactory
01
...
02
03
<!-- A connection to ActiveMQ -->
04
05
<bean id="amqConnectionFactory"
06
07
class="org.apache.activemq.ActiveMQConnectionFactory"
08
09
p:brokerURL='tcp://localhost:61616" />
10
11
12
13
<!-- A cached connection to wrap the ActiveMQ connection -->
14
15
<bean id="cachedConnectionFactory"
16
17
class="org.springframework.jms.connection.CachingConnectionFactory"
18
19
p:targetConnectionFactory-ref="amqConnectionFactory"
20
21
p:sessionCacheSize="10" />
22
23
24
25
<!-- A destination in ActiveMQ -->
26
27
<bean id="destination"
28
29
class="org.apache.activemq.command.ActiveMQQueue">
30
31
<constructor-arg value="FOO.TEST" />
32
33
</bean>
34
35
36
37
<!-- A JmsTemplate instance that uses the cached connection and destination -->
38
39
<bean id="producerTemplate"
40
41
class="org.springframework.jms.core.JmsTemplate"
42
43
p:connectionFactory-ref="cachedConnectionFactory"
44
45
p:defaultDestination-ref="destination" />
46
47
...
As you can see, the configuration for the CachingConnectionFactory along with the JmsTemplate is quite simple. Furthermore, these two classes are also both in the org.springframework.jms package path so they're both included in the spring-jms jar file making their use even easier.
The only thing left to do is utilize the jmsTemplate bean in your Java code to actually send a message. This is shown below:
01
public class SimpleMessageProducer {
02
03
04
05
private static final Logger LOG = Logger.getLogger(SimpleMessageProducer.class);
06
07
08
09
@Autowired
10
11
protected JmsTemplate jmsTemplate;
12
13
14
15
protected int numberOfMessages = 100;
16
17
18
19
public void sendMessages() throws JMSException {
20
21
StringBuilder payload = null;
22
23
24
25
for (int i = 0; i < numberOfMessages; ++i) {
26
27
28
29
payload = new StringBuilder();
30
31
payload.append("Message [").append(i).append("] sent at: ").append(new Date());
32
33
34
35
jmsTemplate.send(new MessageCreator() {
36
37
public Message createMessage(Session session) throws JMSException {
38
39
TextMessage message = session.createTextMessage(payload.toString());
40
41
message.setIntProperty("messageCount", i);
42
43
LOG.info("Sending message number [" + i + "]");
44
45
return message;
46
47
}
48
49
});
50
51
}
52
53
}
54
55
}
The SimpleMessageProducer class above demonstrates the use of Spring autowiring to resolve the relationship between the jmsTemplate property and the producerTemplate in the app context further above. Then an anonymous MessageCreator instance is used to actually create a message for the jmsTemplate to send.
The JmsTemplate and the CachingConnectionFactory are both very widely used in businesses of all sizes throughout the world. Coupled with one of the Spring message listener containers, they provide an ideal solution.
I'll elaborate on message consumption using the Spring DefaultMessageListenerContainer and the SimpleMessageListenerContainer in a future blog post.
Have you ever had a need to create your own JMS consumer? Or will you have this need in the future? If you answered yes to either one of these questions, this post will simplify your life.
In the previous post, I discussed Using the Spring JmsTemplate to Send JMS Messages. As a follow-on, in this post I will demonstrate how to receive messages using Spring JMS. Although the previously mentioned JmsTemplate can receive messages synchronously, here I will focus on asynchronous message reception using the Spring message listener container architecture, specifically the DefaultMessageListenerContainer.
The DefaultMessageListenerContainer (DMLC) is another wonderful convenience class that is part of the Spring Framework's JMS package. As you can see in the Javadoc, the DMLC is not a single class, but a well-abstracted hierarchy for the purpose of receiving messages. The reason for this is that the DMLC takes its inspiration from Message Driven Beans (MDB).
MDBs were originally defined in the EJB 2.0 spec as a stateless, transaction aware message listener that use JMS resources provided by the Java EE container. MDBs can also be pooled by the Java EE container in order to scale up. In short, MDBs were designed for asynchronous message reception in a way that the Java EE container could manage them. Although the intention was good, unfortunately the disadvantages of MDBs are numerous including:
MDBs are static in their configuration and creation (they cannot be created dynamically)
MDBs can only listen to a single destination
MDBs can only send messages after first receiving a message
MDBs require an EJB container (and therefore the Java EE container)
Although the Spring DMLC took its inspiration from MDBs, it did not replicate these disadvantages; quite the opposite, in fact. The Spring DMLC is commonly used to create what have become known as Message-Driven POJOs (MDP). MDPs offer all of the same functionality as MDBs but without the disadvantages listed above. The Spring DMLC provides many features including:
Various levels of caching of the JMS resources (connections and sessions) and JMS consumers for increased performance
The ability to dynamically grow and shrink the number of consumers to concurrently process messages based on load (see setConcurrentConsumers and setMaxConcurrentConsumers) for additional performance
Automatically re-establishes connections if the message broker becomes unavailable
Asynchronous execution of a message listener using the Spring TaskExecutor
Support for local JMS transactions as well as an external transaction manager around message reception and listener execution
Support for various message acknowledgement modes, each providing different semantics
For some situations, it is important to understand the additional error handling and the redelivery semantics that are provided by the DMLC. For more information, see the AbstractMessageListenerContainer JavaDoc.
The reason I recommend the DMLC (or even the SimpleMessageListenerContainer) is because writing JMS consumers can be a lot of work. In doing so, you must manually handle and mange the JMS resources and the JMS consumers, any concurrency that is necessary and any use of transactions. If you've ever done such work you know how arduous and error prone it can be. Certainly MDBs provide some of these features but with all their disadvantages. By creating MDPs using the Spring DMLC, I have seen users save a tremendous amount of time and increase their productivity significantly. This is because the DMLC offers much flexibility, robustness, a high amount of configurability and it has widespread deployment in businesses all over the world (so it has been widely tested).
Compared to MDBs, use of the Spring DMLC is actually surprisingly simple. The easiest way to get started is to using an XML configuration as the Spring DMLC provides JMS namespace support. Below is a Spring application context that demonstrates the configuration to use the Spring DMLC with Apache ActiveMQ:
01
<?xml version="1.0" encoding="UTF-8"?>
02
<beans xmlns="http://www.springframework.org/schema/beans"
03
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
04
xmlns:jms="http://www.springframework.org/schema/jms"
05
xmlns:p="http://www.springframework.org/schema/p"
06
xsi:schemaLocation="
07
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
08
http://www.springframework.org/schema/jms http://www.springframework.org/schema/jms/spring-jms-3.0.xsd">
09
10
<!-- A JMS connection factory for ActiveMQ -->
11
<bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory"
12
p:brokerURL="tcp://foo.example.com:61616" />
13
14
<!-- A POJO that implements the JMS message listener -->
15
<bean id="simpleMessageListener" class="com.mycompany.SimpleMessageListener">
16
17
<!-- The Spring message listener container configuration -->
18
<jms:listener-container
19
container-type="default"
20
connection-factory="connectionFactory"
21
acknowledge="auto">
22
<jms:listener destination="TEST.FOO" ref="simpleMessageListener" method="onMessage" />
23
</jms:listener-container>
24
</beans>
For folks who are already familiar with the Spring Framework, the XML above is quite straightforward. It defines a connection factory bean for ActiveMQ, a message listener bean and the Spring listener-container. Notice that the jms:listener contains the destination name and not the listener-container. This level of separation is important because it means that the listener-container is not tied to any destination, only the jms:listener is. You can define as many jms:listener elements as is necessary for your application and the container will handle them all.
Below is the message listener implementation:
01
import javax.jms.JMSException;
02
import javax.jms.Message;
03
import javax.jms.MessageListener;
04
import javax.jms.TextMessage;
05
06
import org.apache.log4j.Logger;
07
08
public class MyMessageListener implements MessageListener {
09
10
private static final Logger LOG = Logger.getLogger(MyMessageListener.class);
11
12
public void onMessage(Message message) {
13
try {
14
TextMessage msg = (TextMessage) message;
15
LOG.info("Consumed message: " + msg.getText());
16
} catch (JMSException e) {
17
// TODO Auto-generated catch block
18
e.printStackTrace();
19
}
20
}
21
22
}
The message listener implementation is deliberately simple as its only purpose is to demonstrate receiving the message and logging the payload of the message. Although this listener implements the javax.jms.MessageListener interface, there are a total of three options available for implementing a message listener to be used with the Spring DMLC:
The javax.jms.MessageListener - This is what was used in the example above. It is a standardized interface from the JMS spec but handling threading is up to you.
The Spring SessionAwareMessageListener - This is a Spring-specific interface the provides access to the JMS session object. This is very useful for request-response messaging. Just be aware that you must do your own exception handling (i.e., override the handleListenerException method so exceptions are not lost).
The Spring MessageListenerAdapter - This is a Spring-specific interface that allows for type-specific message handling. Use of this interface avoids any JMS-specific dependencies in your code.
So not only is the Spring message listener container easy to use, it is also full of options to adapt to many environments. And I've only focused on the DefaultMessageListenerContainer here, I have not talked about the SimpleMessageListenerContainer (SMLC) beyond a simple mention. At a high level the difference is that the SMLC is static and provides no support for transactions.
One very big advantage of the Spring message listener container is that this type of XML config can be used in a Java EE container, in a servlet container or stand alone. This same Spring application context will run in Weblogic, JBoss, Tomcat or in a stand alone Spring container. Furthermore, the Spring DMLC also works with just about any JMS compliant messaging middleware available. Just define a bean for the JMS connection factory for your MOM and possibly tweak a few properties on the listener-container and you can begin consuming messages from different MOMs.
I should also note that the XML configuration is certainly not a requirement either. You can go straight for the underlying Java classes in your own code if you wish. I've used each style in various situations, but to begin using the Spring DMLC in the shortest amount of time, I find the Spring XML application context the fastest.
http://bsnyderblog.blogspot.com/2010/02/using-spring-jmstemplate-to-send-jms.html
http://bsnyderblog.blogspot.com/2010/02/using-spring-to-receive-jms-messages.html
Recently I stumbled upon a number of places in the some docs and mailing lists where claims are made that the Spring JmsTemplate is full of anti-patterns, is horribly inefficient and shouldn't be used. Well I'm here to debunk these erroneous claims by pointing out a class in the Spring Framework that was overlooked entirely.
The Spring JmsTemplate is a convenience class for sending and receiving JMS messages in a synchronous manner. The JmsTemplate was originally designed to be used with a J2EE container where the container provides the necessary pooling of the JMS resources (i.e., connections, consumers and producers). Such requirements came from the EJB spec. But when developers began using the JmsTemplate outside of J2EE containers, and because some JMS providers do not offer caching/pooling of JMS resources, a different solution was necessary. Enter the Spring CachingConnectionFactory.
The CachingConnectionFactory is meant to wrap a JMS provider's connection to provide caching of sessions, connections and producers as well as automatic connection recovery. By default, it uses a single session to create many connections and this model works very well with most MOMs. But if you need to scale further, you can also specify the number of sessions to cache using the sessionCacheSize property.
Below is a snippet from a Spring app context that demonstrates the configuration for the CachingConnectionFactory
01
...
02
03
<!-- A connection to ActiveMQ -->
04
05
<bean id="amqConnectionFactory"
06
07
class="org.apache.activemq.ActiveMQConnectionFactory"
08
09
p:brokerURL='tcp://localhost:61616" />
10
11
12
13
<!-- A cached connection to wrap the ActiveMQ connection -->
14
15
<bean id="cachedConnectionFactory"
16
17
class="org.springframework.jms.connection.CachingConnectionFactory"
18
19
p:targetConnectionFactory-ref="amqConnectionFactory"
20
21
p:sessionCacheSize="10" />
22
23
24
25
<!-- A destination in ActiveMQ -->
26
27
<bean id="destination"
28
29
class="org.apache.activemq.command.ActiveMQQueue">
30
31
<constructor-arg value="FOO.TEST" />
32
33
</bean>
34
35
36
37
<!-- A JmsTemplate instance that uses the cached connection and destination -->
38
39
<bean id="producerTemplate"
40
41
class="org.springframework.jms.core.JmsTemplate"
42
43
p:connectionFactory-ref="cachedConnectionFactory"
44
45
p:defaultDestination-ref="destination" />
46
47
...
As you can see, the configuration for the CachingConnectionFactory along with the JmsTemplate is quite simple. Furthermore, these two classes are also both in the org.springframework.jms package path so they're both included in the spring-jms jar file making their use even easier.
The only thing left to do is utilize the jmsTemplate bean in your Java code to actually send a message. This is shown below:
01
public class SimpleMessageProducer {
02
03
04
05
private static final Logger LOG = Logger.getLogger(SimpleMessageProducer.class);
06
07
08
09
@Autowired
10
11
protected JmsTemplate jmsTemplate;
12
13
14
15
protected int numberOfMessages = 100;
16
17
18
19
public void sendMessages() throws JMSException {
20
21
StringBuilder payload = null;
22
23
24
25
for (int i = 0; i < numberOfMessages; ++i) {
26
27
28
29
payload = new StringBuilder();
30
31
payload.append("Message [").append(i).append("] sent at: ").append(new Date());
32
33
34
35
jmsTemplate.send(new MessageCreator() {
36
37
public Message createMessage(Session session) throws JMSException {
38
39
TextMessage message = session.createTextMessage(payload.toString());
40
41
message.setIntProperty("messageCount", i);
42
43
LOG.info("Sending message number [" + i + "]");
44
45
return message;
46
47
}
48
49
});
50
51
}
52
53
}
54
55
}
The SimpleMessageProducer class above demonstrates the use of Spring autowiring to resolve the relationship between the jmsTemplate property and the producerTemplate in the app context further above. Then an anonymous MessageCreator instance is used to actually create a message for the jmsTemplate to send.
The JmsTemplate and the CachingConnectionFactory are both very widely used in businesses of all sizes throughout the world. Coupled with one of the Spring message listener containers, they provide an ideal solution.
I'll elaborate on message consumption using the Spring DefaultMessageListenerContainer and the SimpleMessageListenerContainer in a future blog post.
Have you ever had a need to create your own JMS consumer? Or will you have this need in the future? If you answered yes to either one of these questions, this post will simplify your life.
In the previous post, I discussed Using the Spring JmsTemplate to Send JMS Messages. As a follow-on, in this post I will demonstrate how to receive messages using Spring JMS. Although the previously mentioned JmsTemplate can receive messages synchronously, here I will focus on asynchronous message reception using the Spring message listener container architecture, specifically the DefaultMessageListenerContainer.
The DefaultMessageListenerContainer (DMLC) is another wonderful convenience class that is part of the Spring Framework's JMS package. As you can see in the Javadoc, the DMLC is not a single class, but a well-abstracted hierarchy for the purpose of receiving messages. The reason for this is that the DMLC takes its inspiration from Message Driven Beans (MDB).
MDBs were originally defined in the EJB 2.0 spec as a stateless, transaction aware message listener that use JMS resources provided by the Java EE container. MDBs can also be pooled by the Java EE container in order to scale up. In short, MDBs were designed for asynchronous message reception in a way that the Java EE container could manage them. Although the intention was good, unfortunately the disadvantages of MDBs are numerous including:
MDBs are static in their configuration and creation (they cannot be created dynamically)
MDBs can only listen to a single destination
MDBs can only send messages after first receiving a message
MDBs require an EJB container (and therefore the Java EE container)
Although the Spring DMLC took its inspiration from MDBs, it did not replicate these disadvantages; quite the opposite, in fact. The Spring DMLC is commonly used to create what have become known as Message-Driven POJOs (MDP). MDPs offer all of the same functionality as MDBs but without the disadvantages listed above. The Spring DMLC provides many features including:
Various levels of caching of the JMS resources (connections and sessions) and JMS consumers for increased performance
The ability to dynamically grow and shrink the number of consumers to concurrently process messages based on load (see setConcurrentConsumers and setMaxConcurrentConsumers) for additional performance
Automatically re-establishes connections if the message broker becomes unavailable
Asynchronous execution of a message listener using the Spring TaskExecutor
Support for local JMS transactions as well as an external transaction manager around message reception and listener execution
Support for various message acknowledgement modes, each providing different semantics
For some situations, it is important to understand the additional error handling and the redelivery semantics that are provided by the DMLC. For more information, see the AbstractMessageListenerContainer JavaDoc.
The reason I recommend the DMLC (or even the SimpleMessageListenerContainer) is because writing JMS consumers can be a lot of work. In doing so, you must manually handle and mange the JMS resources and the JMS consumers, any concurrency that is necessary and any use of transactions. If you've ever done such work you know how arduous and error prone it can be. Certainly MDBs provide some of these features but with all their disadvantages. By creating MDPs using the Spring DMLC, I have seen users save a tremendous amount of time and increase their productivity significantly. This is because the DMLC offers much flexibility, robustness, a high amount of configurability and it has widespread deployment in businesses all over the world (so it has been widely tested).
Compared to MDBs, use of the Spring DMLC is actually surprisingly simple. The easiest way to get started is to using an XML configuration as the Spring DMLC provides JMS namespace support. Below is a Spring application context that demonstrates the configuration to use the Spring DMLC with Apache ActiveMQ:
01
<?xml version="1.0" encoding="UTF-8"?>
02
<beans xmlns="http://www.springframework.org/schema/beans"
03
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
04
xmlns:jms="http://www.springframework.org/schema/jms"
05
xmlns:p="http://www.springframework.org/schema/p"
06
xsi:schemaLocation="
07
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
08
http://www.springframework.org/schema/jms http://www.springframework.org/schema/jms/spring-jms-3.0.xsd">
09
10
<!-- A JMS connection factory for ActiveMQ -->
11
<bean id="connectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory"
12
p:brokerURL="tcp://foo.example.com:61616" />
13
14
<!-- A POJO that implements the JMS message listener -->
15
<bean id="simpleMessageListener" class="com.mycompany.SimpleMessageListener">
16
17
<!-- The Spring message listener container configuration -->
18
<jms:listener-container
19
container-type="default"
20
connection-factory="connectionFactory"
21
acknowledge="auto">
22
<jms:listener destination="TEST.FOO" ref="simpleMessageListener" method="onMessage" />
23
</jms:listener-container>
24
</beans>
For folks who are already familiar with the Spring Framework, the XML above is quite straightforward. It defines a connection factory bean for ActiveMQ, a message listener bean and the Spring listener-container. Notice that the jms:listener contains the destination name and not the listener-container. This level of separation is important because it means that the listener-container is not tied to any destination, only the jms:listener is. You can define as many jms:listener elements as is necessary for your application and the container will handle them all.
Below is the message listener implementation:
01
import javax.jms.JMSException;
02
import javax.jms.Message;
03
import javax.jms.MessageListener;
04
import javax.jms.TextMessage;
05
06
import org.apache.log4j.Logger;
07
08
public class MyMessageListener implements MessageListener {
09
10
private static final Logger LOG = Logger.getLogger(MyMessageListener.class);
11
12
public void onMessage(Message message) {
13
try {
14
TextMessage msg = (TextMessage) message;
15
LOG.info("Consumed message: " + msg.getText());
16
} catch (JMSException e) {
17
// TODO Auto-generated catch block
18
e.printStackTrace();
19
}
20
}
21
22
}
The message listener implementation is deliberately simple as its only purpose is to demonstrate receiving the message and logging the payload of the message. Although this listener implements the javax.jms.MessageListener interface, there are a total of three options available for implementing a message listener to be used with the Spring DMLC:
The javax.jms.MessageListener - This is what was used in the example above. It is a standardized interface from the JMS spec but handling threading is up to you.
The Spring SessionAwareMessageListener - This is a Spring-specific interface the provides access to the JMS session object. This is very useful for request-response messaging. Just be aware that you must do your own exception handling (i.e., override the handleListenerException method so exceptions are not lost).
The Spring MessageListenerAdapter - This is a Spring-specific interface that allows for type-specific message handling. Use of this interface avoids any JMS-specific dependencies in your code.
So not only is the Spring message listener container easy to use, it is also full of options to adapt to many environments. And I've only focused on the DefaultMessageListenerContainer here, I have not talked about the SimpleMessageListenerContainer (SMLC) beyond a simple mention. At a high level the difference is that the SMLC is static and provides no support for transactions.
One very big advantage of the Spring message listener container is that this type of XML config can be used in a Java EE container, in a servlet container or stand alone. This same Spring application context will run in Weblogic, JBoss, Tomcat or in a stand alone Spring container. Furthermore, the Spring DMLC also works with just about any JMS compliant messaging middleware available. Just define a bean for the JMS connection factory for your MOM and possibly tweak a few properties on the listener-container and you can begin consuming messages from different MOMs.
I should also note that the XML configuration is certainly not a requirement either. You can go straight for the underlying Java classes in your own code if you wish. I've used each style in various situations, but to begin using the Spring DMLC in the shortest amount of time, I find the Spring XML application context the fastest.
发表评论
-
context:component-scan扫描使用上的容易忽略的use-default-filters
2015-11-13 21:28 807问题 如下方式可以成功扫描到@Controller注解的Bea ... -
MongoDB Java Driver操作指南
2015-08-04 21:42 2538MongoDB为Java提供了非常丰富的API操作,相比关系 ... -
Spring3自定义环境配置 <beans profile="">
2015-04-22 10:51 1268摘自springside3 Spring 3.1的功能 ... -
json-rpc 1.0规范解读
2015-04-17 14:21 1318JSON可能是这个地球上 ... -
request.getParameter()、request.getInputStream()和request.getReader()
2015-03-30 11:16 2999大家经常 用servlet和jsp, ... -
微信企业号上传下载多媒体文件接口详解演示-java
2015-03-27 15:37 6299企业在使用接口时,对多媒体文件、多媒体消息的获取和调用等操作 ... -
java如何得到GET和POST请求URL和参数列表
2015-03-13 16:28 3122在servlet中GET请求可以通过HttpServletR ... -
关于<context:property-placeholder>的一个有趣现象
2015-01-05 20:09 566先来看下A和B两个模块 A模块和B模块都分别拥有自己的S ... -
读取配置信息
2014-12-29 18:08 846第一种方法是使用java.io和java.util包,缺点是路 ... -
spring 事件机制
2014-11-14 14:17 974在Spring中已经定义的五 ... -
spring InitializingBean接口
2014-10-27 01:33 637最近工作需要得到sping中的每个事物需要执行的sql, ... -
spring InitializingBean接口
2014-10-27 01:33 964最近工作需要得到sping中的每个事物需要执行的sql,称 ... -
四种常见的 POST 提交数据方式
2014-09-23 11:38 1621HTTP/1.1 协议规定的 HTTP 请求方法有 OPT ... -
使用 Java 配置进行 Spring bean 管理
2014-07-31 17:58 848Spring bean 是使用传统的 XML 方法配置的。在 ... -
怎么使用Servlet 3.0中的上传文件呢?
2014-07-31 15:20 940Spring 3.1开始提供了Servlet 3.0的支持。 ... -
Spring mvc 拓展使用
2014-07-31 15:08 978原文链接:http://my.oschina.net/u/11 ... -
Spring MVC handler method 参数绑定常用的注解
2014-07-31 10:36 1998参考链接:http://csjava.bl ... -
SpringMVC中使用Interceptor拦截器
2014-06-30 15:18 846SpringMVC 中的Interceptor 拦 ... -
AOP的底层实现-CGLIB动态代理和JDK动态代理
2014-05-04 16:58 1035AOP是目前Spring框架中的 ... -
Spring AOP 实现原理与 CGLIB 应用
2014-05-04 16:39 723AOP(Aspect Orient Programmi ...
相关推荐
JMS_ActiveMQ_Spring
详细内容: SpringJMS整合ActiveMQ.doc 详细说明文档 apache-activemq-5.8.0-bin.zip ActiveMQ安装包 JMSTest.rar MyEclipse8.5下web工程
JMS_MQ系统之Spring中嵌入ActiveMQ,JMS_MQ系统之Spring中嵌入ActiveMQ
spring3.0整合了activemQ和jms可以发送信息和接收消息
基于Spring+JMS+ActiveMQ+Tomcat,我使用的版本情况如下所示:Spring 3.2.0,ActiveMQ 5.4.3,Tomcat 6.0.43。本例通过详细的说明和注释,实现消息服务的基本功能:发送与接收。Spring对JMS提供了很好的支持,可以...
本章我将通过spring jms和activemq实现单Web项目服务器间异步访问和多Web项目服务器间异步访问。 一. 简介 1. 什么是Apache ActiveMq Apache ActiveMq是最流行和最强大的开源消息和集成服务器。同时Apache ActiveMq...
Spring+JMS+ActiveMQ+Tomcat jar下载,在博客主页有实例,欢迎换看
基于Spring+JMS+ActiveMQ+Tomcat,我使用的版本情况如下所示: •Spring 2.5 •ActiveMQ 5.4.0 •Tomcat 6.0.30 下面通过学习与配置,实现消息服务的基本功能:发送与接收。Spring对JMS提供了很好的支持,可以...
基于Spring+JMS+ActiveMQ+Tomcat,做一个Spring4.1.0和ActiveMQ5.11.1整合实例,实现了Point-To-Point的异步队列消息和PUB/SUB(发布/订阅)模型,简单实例,不包含任何业务。
使用spring框架 实现消息传递 基于activemq
Spring整合JMS(activeMQ)的示例,开发环境为eclipse+maven
description="JMS Connection Factory" factory="org.apache.activemq.jndi.JNDIReferenceFactory" brokerURL="vm://shirdrnUrl" brokerName="MyActiveMQBroker"/> auth="Container" type="org.apache...
spring activemq 整合,只是一个demo而已 ,初学者看看!, 实际工作用时将jms:listener-container 注释打开,通过监听器根据队列名称映射到不同监听器上去处理。
spring整合JMS-居于ActiveMQ实现
Spring JMS with ActiveMQ – 发送和接收消息示例。 此代码假装是将 ActiveMQ 与 JMS Spring Beans 一起使用的简单概念证明。 这个想法是查找 Spring 上下文来处理 JMS bean。 配置 您需要配置一个名为 BATCH_CONF ...
cJMS之ActiveMQ与Spring整合源码
NULL 博文链接:https://yaozhiqiang109.iteye.com/blog/1073455
JMS-activemq 实例(分ppt,eclipse工程,说明三部分) 特别有readme说明,一看就会用 spring实现方式,可运行有jar包
此实例基于Spring+JMS+ActiveMQ+Tomcat,注解的完整实例,包含jar包
NULL 博文链接:https://ihenu.iteye.com/blog/2270078