users@jms-spec.java.net

[jms-spec users] Re: JMS_SPEC-116: Take advantage of EJB 3.2's RA improvement for MDBs

From: Nigel Deakin <nigel.deakin_at_oracle.com>
Date: Tue, 8 Sep 2015 12:29:10 +0100

(This email refers to my proposals to improve JMS MDBs at 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