@@ -38,8 +38,7 @@ usual (Spring) POJOs. Currently, Spring supports the following remoting technolo
3838* __Hessian__. By using Spring's `HessianProxyFactoryBean` and the
3939 `HessianServiceExporter` you can transparently expose your services using the
4040 lightweight binary HTTP-based protocol provided by Caucho.
41- * __JAX-WS__. Spring provides remoting support for web services via JAX-WS (the
42- successor of JAX-RPC, as introduced in Java EE 5 and Java 6).
41+ * __JAX-WS__. Spring provides remoting support for web services via JAX-WS.
4342* __JMS__. Remoting using JMS as the underlying protocol is supported via the
4443 `JmsInvokerServiceExporter` and `JmsInvokerProxyFactoryBean` classes.
4544* __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
15681567`JmsTransactionManager`). This allows for seamless integration of JMS as a transactional
15691568resource into Spring's transaction management mechanisms.
15701569
1570+ [NOTE]
1571+ ====
1572+ As of Spring Framework 5, Spring's JMS package fully supports JMS 2.0 and requires the
1573+ JMS 2.0 API to be present at runtime. We recommend the use of a JMS 2.0 compatible provider.
1574+
1575+ If you happen to use an older message broker in your system, you may try upgrading to a
1576+ JMS 2.0 compatible driver for your existing broker generation. Alternatively, you may also
1577+ try to run against a JMS 1.1 based driver, simply putting the JMS 2.0 API jar on the
1578+ classpath but only using JMS 1.1 compatible API against your driver. Spring's JMS support
1579+ adheres to JMS 1.1 conventions by default, so with corresponding configuration it does
1580+ support such a scenario. However, please consider this for transition scenarios only.
1581+ ====
1582+
15711583
15721584
15731585[[jms-using]]
0 commit comments