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>
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>
> 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