@@ -38,8 +38,7 @@ usual (Spring) POJOs. Currently, Spring supports the following remoting technolo
38
38
* __Hessian__. By using Spring's `HessianProxyFactoryBean` and the
39
39
`HessianServiceExporter` you can transparently expose your services using the
40
40
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.
43
42
* __JMS__. Remoting using JMS as the underlying protocol is supported via the
44
43
`JmsInvokerServiceExporter` and `JmsInvokerProxyFactoryBean` classes.
45
44
* __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
1567
`JmsTransactionManager`). This allows for seamless integration of JMS as a transactional
1569
1568
resource into Spring's transaction management mechanisms.
1570
1569
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
+
1571
1583
1572
1584
1573
1585
[[jms-using]]
0 commit comments