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