+1
About EJB spec changes, the EE 8 page hints
"Several of the technologies already included in the Java EE platform are
expected to be updated for the Java EE 8 release"
but at least there isn't a brand new EJB JSR for EE 8. Nor has there been a
MR of the recent EJB JSR since its final release.
Did anybody either directly or via Umbrella JSR (Linda, Bill) reach out to
them so far?
Werner
On Wed, Sep 9, 2015 at 3:13 AM, <users-request_at_jms-spec.java.net> wrote:
> Table of contents:
>
> 1. [jms-spec users] Re: JMS_SPEC-116: Take advantage of EJB 3.2's RA
> improvement for MDBs - Nigel Deakin <nigel.deakin_at_oracle.com>
> 2. [jms-spec users] Re: JMS_SPEC-116: Take advantage of EJB 3.2's RA
> improvement for MDBs - Clebert Suconic <clebert.suconic_at_gmail.com>
>
>
>
> ---------- Forwarded message ----------
> From: Nigel Deakin <nigel.deakin_at_oracle.com>
> To: users_at_jms-spec.java.net
> Cc:
> Date: Tue, 8 Sep 2015 12:29:10 +0100
> Subject: [jms-spec users] Re: JMS_SPEC-116: Take advantage of EJB 3.2's RA
> improvement for MDBs
> (This email refers to my proposals to improve JMS MDBs at
> <https://java.net/projects/jms-spec/pages/JMSListener2>
> https://java.net/projects/jms-spec/pages/JMSListener2)
>
> The next issue I'd like to discuss is the
>
> *Relationship between the old and new ways to define a JMS MDB *This
> boils down to the question "should the new annotations be allowed for MDBs
> that implement the javax.jms.MessageListener interface?"
>
> There are two possible cases we need to consider:
>
> - Allowing these new annotations to be used on the legacy onMessage
> method of a javax.jms.MessageListener
>
> Version 2
> <https://java.net/projects/jms-spec/pages/JMSListener2#Specifying_the_callback_method>
> proposed any of the new annotations could be specified. However the
> requirement that the @JMSListener always be specified could not apply
> since that would break existing MDBs.
>
>
> - Allowing these new annotations to be used to define additional
> callback methods (i.e. in addition to the onMessage method).
>
> Version 2
> <https://java.net/projects/jms-spec/pages/JMSListener2#Specifying_the_callback_method>
> proposed that this be allowed so long as the MDB also implemented the
> no-method javax.jms.JMSMessageDrivenBean marker interface.
>
> On reflection, I'm wondering whether this is introducing unnecessary
> complexity. It means that lots of additional use cases need to be defined
> in the spec, implemented, and tested, whilst bringing little benefits to
> users who can convert to a new-style JMS MDB easily enough.
>
> In addition, since we're seeking EJB spec changes to remove the need for
> the javax.jms.JMSMessageDrivenBean marker interface completely, it
> doesn't make any sense to introduce a requirement to use it here.
>
> I'm therefore wondering whether it would be better to make a clear
> distinction between "legacy" JMS MDBs and "new-style" JMS 2.1 MDBs. Here's
> what I'm suggesting:
>
> - Legacy JMS MDBs would implement javax.jms.MessageListener and be
> configured as they are now.
>
>
> - New-style MDBs would not implement javax.jms.MessageListener. They
> would use the new annotations to specify the callback methods. They would
> also implement the javax.jms.JMSMessageDrivenBean marker interface,
> though we're seeking EJB spec changes to remove the need for this.
>
>
> - If the new annotations were used on a MDB which implements
> javax.jms.MessageListener then deployment would fail. This would be a
> mandatory requirement on the application server or resource adapter.
>
> There are other options for combining these features, but I'm suggesting
> that keeping them separate will make things simpler.
>
> What do you think? is this better, or would you prefer the original
> proposal?
>
> Nigel
>
>
> ---------- Forwarded message ----------
> From: Clebert Suconic <clebert.suconic_at_gmail.com>
> To: jms-spec users <users_at_jms-spec.java.net>
> Cc:
> Date: Tue, 8 Sep 2015 16:12:55 -0400
> Subject: [jms-spec users] Re: JMS_SPEC-116: Take advantage of EJB 3.2's RA
> improvement for MDBs
> > What do you think? is this better, or would you prefer the original
> proposal?
>
> +1. I think it's safer to not allow it as you're proposing. It would be
> complicated to allow both and could cause confusion for users and JMS
> implementors.
>
> End of digest for list users_at_jms-spec.java.net - Wed, 09 Sep 2015
>
>