Skip to content

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

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

Closed
spring-projects-issues opened this issue Dec 9, 2018 · 3 comments
Assignees
Labels
in: messaging Issues in messaging modules (jms, messaging) status: backported An issue that has been backported to maintenance branches type: task A general task
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues 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-projects-issues
Copy link
Collaborator Author

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-projects-issues
Copy link
Collaborator Author

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-projects-issues
Copy link
Collaborator Author

João Guilherme de Souza Lima commented

Thank you Juergen, I appreciate.

@spring-projects-issues spring-projects-issues added in: messaging Issues in messaging modules (jms, messaging) status: backported An issue that has been backported to maintenance branches type: task A general task labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.1.4 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: messaging Issues in messaging modules (jms, messaging) status: backported An issue that has been backported to maintenance branches type: task A general task
Projects
None yet
Development

No branches or pull requests

2 participants