New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify whether spring-jms 5.x is still able to run with a JMS 1.1 provider [SPR-17583] #22115

Closed
spring-issuemaster opened this Issue Dec 9, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Dec 9, 2018

João Guilherme de Souza Lima opened SPR-17583 and commented

Starting with 5.0.0, the dependency to the JMS API was changed in spring-jms for 2.0.

Spring documentation and/or javadocs might make clear that this does not mean that spring-jms 5.x actually requires the provider used to implement 2.0.

In my case, I am evaluating the impacts to upgrade some applications I have from spring 4.x to 5.x. For other external dependencies/impacts like for instance JEE APIs like servlet-api or JPA, Spring documentation make this clearer. For instance, LocalContainerEntityManagerFactoryBean's javadoc make it clear that JPA 2.1 is required. As I currently depends on a JMS provider (Oracle AQ) that only implements JMS 1.1, to be sure I would not have issues I had to download spring-jms code and search in it for calls to ConnectionFactory.createContext. Only after doing that I was able to see that there is no such call, and was able to conclude (yet without 100% certainty) that the upgrade of the dependency to 2.0 must have been to allow the spring-jms ConnectionFactory decorators to be 2.0 compliant.

Spring Framework Reference documentation and/or some javadoc (maybe the one of @EnableJms) might make this clear.


Affects: 5.0.3

Issue Links:

Referenced from: commits 7b9c30f, 6505cb9

Backported to: 5.0.12

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Dec 10, 2018

Juergen Hoeller commented

Technically speaking, we require the JMS 2.0 API to be present on the classpath now. At the same time, our common execution paths at runtime still operate according to JMS 1.1 rules, with just optional calls to certain JMS 2.0 methods in certain configuration scenarios.

In practice, this means you'll have to upgrade your JMS API jar to 2.0 for your Spring setup but should be able to run against a JMS 1.1 provider at runtime, being bound to the JMS 2.0 API jar and simply not implementing the new 2.0 methods (which Spring isn't using by default anyway). While such a combination is not recommended, we see the need for it in upgrade scenarios, so we should also document it as "supported under certain constraints".

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Dec 12, 2018

Juergen Hoeller commented

Many parts of Spring's JMS support are effectively still JMS 1.1 compatible, just happen to be compiled against the JMS 2.0 API. It's only really CachingConnectionFactory and co where actual JMS 2.0 runtime dependencies emerge, but even there only to the JMS 2.0 API, still allowing it to be bound to a JMS 1.1 based driver at runtime (as long as the 2.0 API is present).

I've added corresponding documentation notes to several places, in particular the javadoc of the ConnectionFactory decorators and the JMS introduction in the reference documentation.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Dec 12, 2018

João Guilherme de Souza Lima commented

Thank you Juergen, I appreciate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment