Table 5-3. JMS 2.0 Aligned activationConfig Properties
Provides advice to the deployer regarding whether the message-driven bean is
intended to be associated with a Queue or Topic . Values for this property are
javax.jms.Queue and javax.jms.Topic .
Specifies the lookup name of an administratively defined ConnectionFactory
object that will be used for the connection to the JMS provider from which a
message-driven bean will send JMS messages.
Specifies the client identifier that will be used for the connection to the JMS provider
from which a message-driven bean will send JMS messages.
If the message-driven bean is intended to be used with a topic, then the bean
provider can specify the name of a durable subscription with this property and set
the subscriptionDurability property to Durable .
This property is to be used only when a message-driven bean is deployed to a
clustered application server, and the value for this property can be either true
or false . A value of true means that the same durable subscription name or
nondurable subscription will be used for each instance in the cluster. A value of
false means that a different durable subscription name or nondurable subscription
will be used for each instance in the cluster.
Embeddable EJBContainer Now Autocloseable
The embeddable EJBContainer enables the use of EJBs within Java SE applications. The embeddable container
cannot be used within a Java EE environment because it allows both the client-side code and EJBs to reside within
the same JVM container. That said, it is noteworthy that the embeddable EJBContainer has been updated in EJB 3.2
in order to bring it inline with more current Java 7 coding techniques.
When using an EJBContainer , it is important to close it when finished. To do so, a client can directly invoke the
container's close method. As of EJB 3.2, the close method can also be invoked via the try-with-resources statement
because the EJBContainer now implements the java.lang.AutoCloseable interface.
New Features in EJB Lite
EJB Lite was introduced in the 3.1 release, and it allows developers to utilize a subset of EJB functionality, without
the requirement to package the entire API. The EJB 3.2 release includes a couple of new features for the EJB Lite
configuration. One of those features is asynchronous session bean invocation. In EJB 3.1, this ability was added to
session beans; previously the only way to asynchronously invoke a method within an enterprise bean was to utilize
a message-driven bean. When asynchronous session bean invocation was introduced, it was only made part of the EJB
full implementation. However, it was later determined that those using EJB Lite would also benefit from the feature.
Although asynchronous session bean invocation has been around a while, I will go through a brief example
for those who are not yet familiar with the topic. To mark an EJB method as asynchronous, simply annotate the
method with @Asynchronous . When a method that is annotated with @Asynchronous is invoked, the call will
return immediately, allowing other work to be performed while the method invocation runs in the background.
The container ensures that the method is executed to completion. It is most common to see asynchronous
methods with a void return type; however, it is certainly possible to return a value using a return type of
java.util.concurrent.Future<V> , where V represents the type of the asynchronous return,
an AsyncResult<V> object.