(I'm switching back to using just users_at_jms-spec.java.net. Using both lists is just confusing)
I completely agree. We don't want JMS MDBs to have to implement the JMSMessageDrivenBean interface. It should be
sufficient to identify them as MDBs and add the appropriate listener annotations.
Here's some detail to explain.
This is all about making it possible to implement flexible MDBs (feel free to suggest a better name) using a resource
adapter. When a resource adapter is being used, it's the resource adapter that has the responsibility of invoking the
callback method on the MDB instance. However the resource adapter doesn't have access to the MDB instance itself, it has
access to an instance of javax.resource.MessageEndpoint, which is a proxy provided by the resource adapter. The reason
for using a proxy is to allow the application server to wrap additional behaviour around the callback method when it is
called (e.g. to handle exceptions in accordance with the EJB spec).
As things stand currently, the proxy will implement the MessageEndpoint interface (giving methods like beforeDelivery)
and the message listener interface implemented by the MDB, e.g. javax.jms.MessageListener (giving the method
onMessage). This allows the resource adapter to use reflection to invoke onMessage.
However in our flexible MDB proposals the callback method isn't defined by an interface. It's defined by annotations.
Prior to EJB 3.2 this would mean that there is no way that a resource adapter could invoke such callback methods.
With this very issue in mind, EJB 3.2 introduced a new feature. This is defined in EJB 3.2 section 5.6.5 "Message-Driven
Bean with No-Methods Listener Interface" This says that if the MDB implements a "no-methods listener interface" then the
MessageEndpoint proxy will implement all the public methods of the MDB. This allows the resource adapter to access them
using reflection.
This is why the current proposals for flexible MDBs require the MDB to implement a no-methods listener interface.
I have proposed that the EJB spec be changed to remove the need for this no-methods interface. I've logged this in the
EJB spec JIRA as
https://java.net/jira/browse/EJB_SPEC-126 . I've discussed this with the EJB maintenance lead (Linda
DeMichel) and I'm hopeful that we'll be able to get an EJB maintenance release (MR) which includes this change. (On 24
September Linda wrote to users_at_ejb-spec.java.net to say "While we are not planning a new EJB JSR for Java EE 8, it is
likely that we will need a small maintenance release to address consistency with regard to planned enhancements to other
specs.")
Although getting this EJB spec change is likely, there are technical issues such as backward compatibility to consider,
so I don't want to make JMS 2.1 dependent on this change. My draft Chapter 16 is therefore designed to work with the
current version of EJB and so requires a no-methods interface JMSMessageDrivenBean. However I am optimistic that we'll
be able to remove this requirement before JMS is actually released.
Nigel
On 30/09/2015 18:17, Clebert Suconic wrote:
> Just answering my own question on I:
>
> Just realized this on your text:
>
> "The need to implement a no-methods marker interface (JMSMessageDrivenBean) is a requirement of EJB 3.2 It is hoped to
> remove this requirement before this specification is released. In that case a flexible JMS MDB would not need to
> implement any interface. All that would be needed would be to identify the callback methods."
>
> Really??? That sucks!!! Can't we change this on EJB 3.x or whatever?
>
>
> On Wed, Sep 30, 2015 at 1:14 PM, Clebert Suconic <clebert.suconic_at_gmail.com <mailto:clebert.suconic_at_gmail.com>> wrote:
>
>
> Why the "Flexible MDB" need to implement any interface?
>
> Couldn't you define it by just the annotation?
>
> On this case:
>
>
> @MessageDriven public class MyMessageBean { // -- no need for this IMO implements JMSMessageDrivenBean {
>
> @JMSQueueListener(destinationLookup="java:global/requestQueue") public void myMessageCallback(Message message) {
>
> ... }
>
> }
>
>
> >> * Extending this to allow batch delivery (as proposed by Clebert)
>
> I think it should be able to accept arrays... and you should be able to determine a Batch annotation with
> completion timeout and the batch size.
>
> I remember you proposed an annotation for such things.
>
>
> This could/should work with either single messages on which case batching is done under covers, or an array on
> which case the batch happens explicitly to the user.
>
>
> IMO This is getting more important this year... IoT is driving more users on Messaging (no matter which vendor
> there) and MDBs will become a bottleneck. (users won't use MDBs at all on those cases, but if we do this
> improvement it would bring a huge gain for that kind of usecase).
>
>
>
>
>
>
> On Wed, Sep 30, 2015 at 1:00 PM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> wrote:
>
> Following feedback and discussions I've now taken the proposals to improve JMS MDBs to the next stage, which
> is to draft a new chapter for the JMS specification. This is chapter 16 "JMS Message-driven beans".
>
> This can be downloaded from https://java.net/downloads/jms-spec/JMS%202.1/JMS21_EDR1_RC1_CH16.pdf
> I've updated the Javadocs to match; these are in the same place as before,
> https://jms-spec.java.net/2.1-SNAPSHOT/apidocs/
>
> (Let me know if you have any trouble accessing this)
>
> The main change since version 2 is to replace a single @JMSListener annotation with three separate
> annotations, @JMSQueueListener, @JMSDurableTopicListener and @JMSNonDurableTopicListener. When I floated this
> earlier everyone who responded seemed in favour.
>
> I've adopted the term "flexible JMS MDBs" to describe this new feature. Any better suggestions?
>
> In addition I have pored over the detailed wording to try to make it as precise and unambiguous as possible.
> I've attempted to describe the required behaviour after an exception is thrown or a conversion error is
> encountered to be similar to the (rather vague) wording of the existing spec.
>
> I've inserted notes to say that a number of aspects still need further work. These are:
>
> * Moving the description of "classic JMS MDBs" from the EJB specification to JMS 2.1
> * Seeking changes to the EJB specification to remove the need to implement the JMSMessageDrivenBean marker
> interface
> * Deciding whether or not a JMS MDB should be allowed to have multiple callback methods
> * How to handle conversion errors when trying to set method parameters
> * How to handle checked exceptions thrown by the callback method
>
> At a future stage we also need to consider
> * Extending this to allow batch delivery (as proposed by Clebert)
> * Defining redelivery behaviour if the MDB throws an exception (as proposed in the original JSR): redelivery
> limits, dead message queues etc.
>
> Please take a look and let me know what you think.
>
> Thanks,
>
> Nigel
>
>
>
>
> --
> Clebert Suconic
>
>
>
>
> --
> Clebert Suconic