@ -38,8 +38,7 @@ usual (Spring) POJOs. Currently, Spring supports the following remoting technolo
@@ -38,8 +38,7 @@ usual (Spring) POJOs. Currently, Spring supports the following remoting technolo
* __Hessian__. By using Spring's `HessianProxyFactoryBean` and the
`HessianServiceExporter` you can transparently expose your services using the
lightweight binary HTTP-based protocol provided by Caucho.
* __JAX-WS__. Spring provides remoting support for web services via JAX-WS (the
successor of JAX-RPC, as introduced in Java EE 5 and Java 6).
* __JAX-WS__. Spring provides remoting support for web services via JAX-WS.
* __JMS__. Remoting using JMS as the underlying protocol is supported via the
`JmsInvokerServiceExporter` and `JmsInvokerProxyFactoryBean` classes.
* __AMQP__. Remoting using AMQP as the underlying protocol is supported by the Spring
@ -1568,6 +1567,19 @@ implementation of Spring's `PlatformTransactionManager` for JMS (the cunningly n
@@ -1568,6 +1567,19 @@ implementation of Spring's `PlatformTransactionManager` for JMS (the cunningly n
`JmsTransactionManager`). This allows for seamless integration of JMS as a transactional
resource into Spring's transaction management mechanisms.
[NOTE]
====
As of Spring Framework 5, Spring's JMS package fully supports JMS 2.0 and requires the
JMS 2.0 API to be present at runtime. We recommend the use of a JMS 2.0 compatible provider.
If you happen to use an older message broker in your system, you may try upgrading to a
JMS 2.0 compatible driver for your existing broker generation. Alternatively, you may also
try to run against a JMS 1.1 based driver, simply putting the JMS 2.0 API jar on the
classpath but only using JMS 1.1 compatible API against your driver. Spring's JMS support
adheres to JMS 1.1 conventions by default, so with corresponding configuration it does
support such a scenario. However, please consider this for transition scenarios only.