Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Support JMS 2.0 and Jakarta Messaging 3.0 API #180

Closed
11 tasks done
acogoluegnes opened this issue Jul 4, 2022 · 0 comments
Closed
11 tasks done

Support JMS 2.0 and Jakarta Messaging 3.0 API #180

acogoluegnes opened this issue Jul 4, 2022 · 0 comments
Assignees
@acogoluegnes
Labels
usability

Comments

@acogoluegnes
Copy link
Contributor

acogoluegnes commented Jul 4, 2022 •
edited

Background

RabbitMQ JMS Client 2.x supports JMS 1.1 API, it requires Java 8. This is the current version of the library.

JMS 2.0 introduces API changes and some new features. A JMS 2.0 client library must implement these changes. From an application developer's point of view, upgrading from JMS 1.1 to JMS 2.0 is transparent, minus some minor changes in the semantics of some methods. JMS 2.0 requires Java 8.

In 2018, as part of the Java EE to Jakarta EE migration, JMS became Jakarta Messaging, and Jakarta Messaging 3.0 was released. It requires Java 11. The name of the Java packages changed, so JMS 2.0 and Jakarta Messaging 3.0 are not compatible. Jakarta Message 3.0 does not bring any other changes though, so moving from JMS 2.0 to Jakarta Messaging 3.0 does not require much effort for a JMS client library.

Note: Jakarta Messaging 3.1 is available, with minor tweaks.

Spring 6.0 (not released yet) will support Jakarta EE, and so Jakarta Messaging.

Impact

The RabbitMQ JMS Client Library is a proven solution to migrate legacy systems to RabbitMQ with minor changes to existing JMS applications. The library can be used on its own or with Spring JMS support.

The implementation of JMS 2.0 does not seem to be essential to users, as it's been requested only once in the last 6 years IIRC. The new features may not be critical and Spring JMS is a good substitute for the API improvements.

Staying compatible with Spring does matter: questions and issues from the community channels reference Spring often. It seems appropriate to keep up with Spring 6.0 by supporting Jakarta Messaging 3.0.

Possible Roadmap

It's not realistic to go only with Jakarta Messaging, so we'll have to maintain 2 branches:

  • 2.x: JMS 1.1 or JMS 2.0, Java 8 or more.
  • 3.x: Jakarta Messaging 3.0, Java 11 or more.

It may be technically possible to support JMS 2.0 in 2.x, but this should also let the choice to use JMS 1.1.

A possible implementation path would be to support JMS 2.0 in 2.x and supporting Jakarta Messaging 3.0 in 3.x would be just a matter of renaming packages.

Resources

JMS 1.1 to JMS 2.0:

JMS 2.0 specification (rev. a), section "1.2. What is new in JMS 2.0?" for an overview and "A.1. Version 2.0" for details.

Jakarta Messaging TCK

JMS 1.1 specification

Tasks
@acogoluegnes acogoluegnes added this to the 3.0.0 milestone Jul 4, 2022
@acogoluegnes acogoluegnes mentioned this issue Sep 26, 2022
Closed
acogoluegnes added a commit that referenced this issue Sep 26, 2022
@acogoluegnes
Bump JMS to 2.0
1d2129c 
Update just the dependency and throw UnsupportedOperationExceptions for each JMS 2.0 methods.

References #180
@acogoluegnes acogoluegnes mentioned this issue Sep 26, 2022
Merged
acogoluegnes added a commit that referenced this issue Sep 26, 2022
@acogoluegnes
Bump JMS to 2.0
72a6d1e 
Update just the dependency and throw UnsupportedOperationExceptions for each JMS 2.0 methods.

References #180

Fixes #197
@acogoluegnes acogoluegnes mentioned this issue Sep 26, 2022
Closed
acogoluegnes added a commit that referenced this issue Sep 26, 2022
@acogoluegnes
Implement JMS 2.0 body extraction methods
dbe2286 
From JMS Specification 3.1:
"A.3.15. New method to extract the body directly from a Message (JMS_SPEC-101)"

https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1.html#new-method-to-extract-the-body-directly-from-a-message-jms_spec-101

References #180

Fixes #199
acogoluegnes added a commit that referenced this issue Sep 26, 2022
@acogoluegnes
Test body extraction for ObjectMessage
3572b47 
References #180, #199
@acogoluegnes acogoluegnes mentioned this issue Sep 26, 2022
Closed
acogoluegnes added a commit that referenced this issue Sep 26, 2022
@acogoluegnes
Add JMS 2.0 new methods to create a session (JMS_SPEC-45)
2c3fac5 
JMS 3.1 spec "A.3.6. New methods to create a session (JMS_SPEC-45)"
https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1.html#new-methods-to-create-a-session-jms_spec-45

Fixes #200

References #180
@acogoluegnes acogoluegnes mentioned this issue Sep 26, 2022
Closed
acogoluegnes added a commit that referenced this issue Sep 26, 2022
@acogoluegnes
Add new createDurableConsumer JMS 2.0 methods (JMS_SPEC-51)
0037dee 
JMS 3.1 spec: A.3.6. New methods to create a session (JMS_SPEC-45)
https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1.html#new-methods-to-create-a-session-jms_spec-45

Fixes #201

References #180
@acogoluegnes acogoluegnes mentioned this issue Sep 27, 2022
Closed
acogoluegnes added a commit that referenced this issue Sep 27, 2022
@acogoluegnes
Make JMSXDeliveryCount mandatory
197fddd 
JMS 3.1 spec, "A.3.13. JMSXDeliveryCount (JMS_SPEC-42)"
https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1.html#jmsxdeliverycount-jms_spec-42

The header is set on every message:
 * to 1 for each message which is not redelivered
 * to the value of the AMQP `x-delivery-count` header + 1 for
a delivered message and if the header is present (for *quorum queues* only)
 * to 2 for a delivered message and if the AMQP `x-delivery-count` header
is not present

References #180

Fixes #202
@acogoluegnes acogoluegnes self-assigned this Sep 27, 2022
acogoluegnes added a commit that referenced this issue Sep 27, 2022
@acogoluegnes
Add flag to enable subscription name validation
a073da5 
JMS 3.1 Spec "A.3.16. Subscription name characters and length"
https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1.html#subscription-name-characters-and-length-2

The validation can be enabled with a flag, it's disabled by default,
to avoid breaking existing code.

The flag is RMQConnectionFactory#validateSubscriptionNames.

References #180

Fixes #203
acogoluegnes added a commit that referenced this issue Sep 29, 2022
@acogoluegnes
Support JMS 2.0 asynchronous send
070d7de 
Enable publisher confirms as soon as one of the MessageProducer
send methods with a CompletionListener parameter is used.
This will enable publisher confirms on all the MessageProducer instances
the owning session created or will create, because they share
the same AMQP channel.

Messages sent with the "sync" methods will use automatically
an empty CompletionListener.

The ConfirmListener API is now deprecated in favor of the async send
methods and the 2 mechanisms should not be used at the same time.

References #180

Fixes #205, #206
@acogoluegnes acogoluegnes mentioned this issue Oct 21, 2022
Closed
acogoluegnes added a commit that referenced this issue Oct 21, 2022
@acogoluegnes
Start support for shared topic subscriptions
5170246 
Created subscription-related classes to handle the subscription
logic and wired them to the existing code and the new methods.

WIP, some verification logic and a bit of plumbing remain.

References #208, #180
acogoluegnes added a commit that referenced this issue Nov 4, 2022
@acogoluegnes
Support shared topic subscriptions
db74862 
Implement the validation rules from section 8.3 of the JMS 3.1 specification.
Make sure a shared non-durable subscription is cleaned up properly
when its consumers are closed.

References #208, #180
@acogoluegnes acogoluegnes mentioned this issue Nov 9, 2022
Closed
acogoluegnes added a commit that referenced this issue Nov 9, 2022
@acogoluegnes
Implement JMS 2.0 simplified API
55356cc 
References #180
Fixes #210
@acogoluegnes acogoluegnes changed the title Support Jakarta Messaging 3.0 API Support JMS 2.0 and Jakarta Messaging 3.0 API Nov 9, 2022
acogoluegnes added a commit that referenced this issue Nov 10, 2022
@acogoluegnes
Bump JMS to 2.0
88feaf0 
Update just the dependency and throw UnsupportedOperationExceptions for each JMS 2.0 methods.

References #180

Fixes #197
acogoluegnes added a commit that referenced this issue Nov 10, 2022
@acogoluegnes
Implement JMS 2.0 body extraction methods
4db5923 
From JMS Specification 3.1:
"A.3.15. New method to extract the body directly from a Message (JMS_SPEC-101)"

https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1.html#new-method-to-extract-the-body-directly-from-a-message-jms_spec-101

References #180

Fixes #199
acogoluegnes added a commit that referenced this issue Nov 10, 2022
@acogoluegnes
Test body extraction for ObjectMessage
e7263b1 
References #180, #199
acogoluegnes added a commit that referenced this issue Nov 10, 2022
@acogoluegnes
Add JMS 2.0 new methods to create a session (JMS_SPEC-45)
51e259a 
JMS 3.1 spec "A.3.6. New methods to create a session (JMS_SPEC-45)"
https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1.html#new-methods-to-create-a-session-jms_spec-45

Fixes #200

References #180
acogoluegnes added a commit that referenced this issue Nov 10, 2022
@acogoluegnes
Add new createDurableConsumer JMS 2.0 methods (JMS_SPEC-51)
e2b060a 
JMS 3.1 spec: A.3.6. New methods to create a session (JMS_SPEC-45)
https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1.html#new-methods-to-create-a-session-jms_spec-45

Fixes #201

References #180
acogoluegnes added a commit that referenced this issue Nov 10, 2022
@acogoluegnes
Make JMSXDeliveryCount mandatory
59cc8b3 
JMS 3.1 spec, "A.3.13. JMSXDeliveryCount (JMS_SPEC-42)"
https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1.html#jmsxdeliverycount-jms_spec-42

The header is set on every message:
 * to 1 for each message which is not redelivered
 * to the value of the AMQP `x-delivery-count` header + 1 for
a delivered message and if the header is present (for *quorum queues* only)
 * to 2 for a delivered message and if the AMQP `x-delivery-count` header
is not present

References #180

Fixes #202
acogoluegnes added a commit that referenced this issue Nov 10, 2022
@acogoluegnes
Add flag to enable subscription name validation
4c33253 
JMS 3.1 Spec "A.3.16. Subscription name characters and length"
https://jakarta.ee/specifications/messaging/3.1/jakarta-messaging-spec-3.1.html#subscription-name-characters-and-length-2

The validation can be enabled with a flag, it's disabled by default,
to avoid breaking existing code.

The flag is RMQConnectionFactory#validateSubscriptionNames.

References #180

Fixes #203
acogoluegnes added a commit that referenced this issue Nov 10, 2022
@acogoluegnes
Support JMS 2.0 asynchronous send
93702d0 
Enable publisher confirms as soon as one of the MessageProducer
send methods with a CompletionListener parameter is used.
This will enable publisher confirms on all the MessageProducer instances
the owning session created or will create, because they share
the same AMQP channel.

Messages sent with the "sync" methods will use automatically
an empty CompletionListener.

The ConfirmListener API is now deprecated in favor of the async send
methods and the 2 mechanisms should not be used at the same time.

References #180

Fixes #205, #206
acogoluegnes added a commit that referenced this issue Nov 10, 2022
@acogoluegnes
Start support for shared topic subscriptions
053e7ac 
Created subscription-related classes to handle the subscription
logic and wired them to the existing code and the new methods.

WIP, some verification logic and a bit of plumbing remain.

References #208, #180
acogoluegnes added a commit that referenced this issue Nov 10, 2022
@acogoluegnes
Support shared topic subscriptions
487f957 
Implement the validation rules from section 8.3 of the JMS 3.1 specification.
Make sure a shared non-durable subscription is cleaned up properly
when its consumers are closed.

References #208, #180
acogoluegnes added a commit that referenced this issue Nov 10, 2022
@acogoluegnes
Implement JMS 2.0 simplified API
e5f4714 
References #180
Fixes #210
acogoluegnes added a commit that referenced this issue Nov 10, 2022
@acogoluegnes
Support client ID set/get in JMSContext
158218b 
The client ID must be set right after the connection creation,
so before the connection can even create a session.
This makes the state of a JMSContext hard to create, because
the session must then be created lazily (instead of being
able to use a final property for it).

References #180, #210
@acogoluegnes acogoluegnes modified the milestones: 3.0.0, 2.7.0 Nov 10, 2022
acogoluegnes added a commit that referenced this issue Dec 7, 2022
@acogoluegnes
Polish delivery delay support
e261a59 
References #180, #222
acogoluegnes added a commit that referenced this issue Dec 7, 2022
@acogoluegnes
Merge pull request #219 from rabbitmq/support-delayed-exchange
e3c33fe 
Support Delayed messages

References #180
Fixes #222
acogoluegnes added a commit that referenced this issue Dec 7, 2022
@acogoluegnes
Polish delivery delay support
ad1aeb1 
References #180, #222

(cherry picked from commit e261a59)

Conflicts:
	src/test/java/com/rabbitmq/TestUtils.java
	src/test/java/com/rabbitmq/integration/tests/DelayedAMQPQueueMessageIT.java
	src/test/java/com/rabbitmq/integration/tests/DelayedQueueMessageIT.java
	src/test/java/com/rabbitmq/integration/tests/DelayedTopicMessageIT.java
	src/test/java/com/rabbitmq/integration/tests/SSLSimpleTopicMessageIT.java
	src/test/java/com/rabbitmq/jms/client/RMQSessionTest.java
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@acogoluegnes acogoluegnes

Labels
usability
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@acogoluegnes