George,
On 24/04/2015 23:49, karabot_at_gmail.com wrote:
> Hello fellow JMS users.
>
> Is there such a feature that will allow for a class to receive messages
> without implementing the MessageListener interface?
>
> Going though the JMS Spec 2.0 I see no such indication.
>
> I am only asking because one of my colleagues was claiming such a
> feature does exist.
Just to add to the points already made:
Currently the only way to receive messages *asynchronously* in JMS is to implement a class which implements the
MessageListener interface. This defines a single method, void onMessage(Message m), which is invoked when a message is
delivered.
* If you're writing a Java EE application you then need to add some additional annotations and/or a deployment
descriptor to turn it into a MDB (message-driven bean) which you can then deploy into a Java EE application server.
* If you're not using Java EE then your code needs to create an instance of your listener class and register it with the
JMS provider using the setMessageListener method on a JMSConsumer or MessageConsumer object.
MDBs are a general-purpose mechanism for receiving objects asynchronously in a Java EE application server. Most people
use MDBs for receiving JMS messages. It is possible, if you want to configure the necessary plumbing (deploy a suitable
resource adapter), to use them to receive other types of object.
Over the years many people have complained that the need to implement javax.jms.MessageListener is restrictive and
proposed improvements. Some of these are logged as proposals in the JMS specification issue tracker:
https://java.net/jira/browse/JMS_SPEC-100
Allow Java EE components other than MDBs to consume messages asynchronously
https://java.net/jira/browse/JMS_SPEC-134
Declarative Annotation Based JMS Listeners
https://java.net/jira/browse/JMS_SPEC-116
Take advantage of EJB 3.2's RA improvement for MDBs
https://java.net/jira/browse/JMS_SPEC-36
Allow messages to be delivered asynchronously in batches
(mentioned just now by Clebert)
The JMS 2.0 expert group did start discussing some possible improvements but I took the decision to defer these to a
later version and to focus on the "simplified API" instead, which offers a simpler API for sending messages.
When JMS 2.1 gets under way (any day now!), this will one of its top priorities.
Nigel
(JMS spec lead)