Linda/all,
I assume JMS 2.1 would be part of EE 8, given v 2 was only the first major
overhaul in years?;-)
I'd be happy to be listed as Supporting this JSR, too.
Regards,
Werner
Am 14.07.2014 21:21 schrieb "Linda DeMichiel" <linda.demichiel_at_oracle.com>:
> 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
>
>
>
>
>
>