users@javaee-spec.java.net

[javaee-spec users] [jsr342-experts] JMS 2.1 JSR

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Mon, 14 Jul 2014 12:16:06 -0700

I'm forwarding below a message on the JMS 2.1 JSR from Nigel Deakin,
our JMS spec lead. Again, we would welcome your support on this JSR.

Please let us know if you or your company would like to be listed as a
supporter of the JSR. Our plan is to submit this some time in
August, so please send me your response before then.

Please also feel free to send any suggestions you might have with
regard to the content of the JSR to me or, better, to Nigel.
We may not be able to accommodate more than minor comments before
submission of the JSR, but of course its final content will be
discussed and decided by the normal Expert Group processes once the
new group is underway.

thanks,

- Linda


-------- Original Message --------
Subject: JMS 2.1 Draft JSR
Date: Mon, 07 Jul 2014 20:41:47 +0100
From: Nigel Deakin <nigel.deakin_at_oracle.com>
Organization: Oracle Corporation
To: jsr343-experts_at_jms-spec.java.net

I have been asked to prepare a draft JSR to propose a new version of the
JMS specification: JMS 2.1, to form part of the
Java EE 8 platform as well as remaining a standalone API.

You can read the draft on the JMS spec wiki here:
https://java.net/projects/jms-spec/pages/JMS21JSRDraft1

I have also started a general page about JMS 2.1 here (aimed at the
wider community):
https://java.net/projects/jms-spec/pages/JMS21

I plan to submit this within the next few weeks.

The main proposal is to continue the ease-of-use improvements started in
JMS 2.1 with a complete overhaul of the API for
asynchronously consuming messages. For Java EE applications I'm
proposing we define an easier-to-use and more general
alternative to JMS message-driven beans. Although I've got some ideas,
nothing is fixed and the expert group will have
full scope to decide what is best. The intention, though, is one for
which I believe there is general support: to
provide a simpler and more compact syntax than JMS MDBs, which will
avoid the restrictions of both the JMS
MessageListener interface and the MDB lifecycle, and which make use of
the features of CDI where possible.

I've also proposed a number of other features, based on our existing
JIRA issue list at
https://java.net/projects/jms-spec/pages/JMS21Planning . Many of these
were already raised or discussed for JMS 2.0 but
we didn't have time to include them.

This isn't intended to be a complete list, but a starting point for the
work of the expert group. Several of the
features included in JMS 2.0 were not mentioned in the initial JSR but
were added later in response to community
proposals, whilst some of the features proposed in the JMS 2.0 JSR never
made it into the spec. I expect the same will
apply to JMS 2.1.

I'd welcome comments on the content of this draft JSR. It may not be
able to accommodate more than minor comments before
submission of the JSR; the final content of the spec will of course be
discussed and decided
as part of the normal Expert Group processes once the new JSR is underway.

In addition, please let me know if you wish to be listed in the JSR
proposal as a supporter, particularly if you
represent a JMS vendor.

Thanks,

Nigel