Spring/spring-framework
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Explicit documentation notes on JMS 2.0 vs 1.1 compatibility

Browse Source 
Issue: SPR-17583

(cherry picked from commit 7b9c30f26e)
This commit is contained in:
Juergen Hoeller
2018-12-12 12:15:34 +01:00
parent a9b453d79f
commit 6505cb93ed
6 changed files with 42 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
src/docs/asciidoc/integration.adoc
View File

@@ -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
`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.
====
[[jms-using]]