Messaging and developing MDBs - EJB 3 in Action - page 145

Notice that all three of the annotation's arguments are optional. If you're a minimalist, you
can keep the annotation as simple as this and leave any details to be added elsewhere, such
as in the deployment descriptor (or simply use the default values):

@MessageDriven
public class TurtleShippingRequestMessageBean

The first element, name , specifies the name of the MDB if you need to explicitly assign
it. If the name element is omitted, the code uses the name of the class, TurtleShip-
pingRequestMessageBean , in the example. The second parameter, mes-
sageListenerInterface , specifies which message listener the MDB implements.
The third parameter, activationConfig , is used to specify listener-specific configur-
ation properties. Let's take a closer look at these last two parameters.

4.3.5. Implementing the MessageListener

The container uses the MessageListener interface implemented by the MDB to re-
gister the MDB with the underlying JMS message provider. Once registered, the provider
can pass along incoming messages by invoking the implemented methods on the MDB
class. Using the messageListenerInterface parameter of the @MessageDriven
annotation is just one way to specify the MessageListener interface. The following
code shows how it's done:

@MessageDriven(
messageListenerInterface="javax.jms.MessageListener")
public class ShippingRequestProcessor {

But most often you'll omit this parameter and specify the interface using the Java imple-
ments keyword, just as you did in listing 4.2

.

Yet another option is to specify the MessageListener interface through the XML de-
ployment descriptor and leave this detail out of the code altogether:

<ejb-jar...>
<enterprise-beans>
<message-driven>
...
<messaging-type> javax.jms.MessageListener</messaging-type>
</message-driven>