I have raised this JIRA issue
http://java.net/jira/browse/JMS_SPEC-55
This is a companion issue to
http://java.net/jira/browse/JMS_SPEC-54 (Define a standard way to configure the destination
on which a JMS MDB consumes messages) and is part of my goal to standardise the way in which MDB applications are written.
This isn't actually a JMS issue, it's a MDB issue, though I haven't reviewed this yet with the Java EE and EJB spec leads.
The issue description is below, but it may be easier to read the formatted version using the JIRA link above.
This proposal suggests some new XML element and annotation attribute names: I expect these will be subject to change.
As always, comments welcome. There are some alternative options below. Which do you prefer?
a) Neither
b) New mandatory activation property connectionFactoryJndiName
c) New element <connection-factory-jndi-name> and corresponding annotation @MessageDriven(connectionFactoryJndiName=...
d) Both b) and c)
Nigel
This is a request for the EJB specification to define a standard way to configure the connection factory used by a MDB
to consume messages.
Currently there is no standard way to do this, and vendors differ in the way in which connection information is
specified in a MDB. Some vendors support an activation property connectionFactoryJndiName but this is not defined in the
EJB 3.1 (or the JCA 1.6) specifications and support for it is not universal. In fact some vendors expect connection
information to be specified directly using non-standard activation properties rather than via a connection factory.
This limits the portability of applications between different JMS providers, resource adapters and application servers.
Two alternatives are proposed:
1. Define a mandatory activation property connectionFactoryJndiName
This would make it mandatory for application servers to support the activation property connectionFactoryJndiName. This
would essentially standardise what some vendors support already.
This could be specified in ejb-jar.xml as follows:
<ejb-jar>
<enterprise-beans>
<message-driven>
<ejb-name>MyMDB</ejb-name>
<activation-config>
<activation-config-property>
<activation-config-property-name>connectionFactoryJndiName</activation-config-property-name>
<activation-config-property-value>jms/connectionFactory</activation-config-property-value>
</activation-config-property>
<activation-config> ...
...or using annotation as follows:
@MessageDriven(
activationConfig = {
@ActivationConfigProperty(
propertyName="connectionFactoryJndiName", propertyValue="jms/connectionFactory")
})
public class MyMDB implements MessageListener {
....
2. Define a new element under the <message-driven> element and a corresponding annotation
This option would propose that the <message-driven> element in ejb-jar.xml be extended to define an addition sub-element
which can be used to specify the JNDI name of the connection factory used by a JMS message-driven bean to consume
messages. A suggested element name is <connection-factory-jndi-name>:
<ejb-jar>
<enterprise-beans>
<message-driven>
<ejb-name>MessageBean</ejb-name>
<message-destination-type>javax.jms.Queue</message-destination-type>
<connection-factory-jndi-name>jms/connectionFactory<connection-factory-jndi-name>
...
To provide an equivalent annotation, a new attribute would need to be added to the @MessageDriven annotation. A
suggested name is connectionFactoryJndiName:
@MessageDriven(connectionFactoryJndiName="jms/connectionFactory")
public class MyMDB implements MessageListener {
....
It might be asked why this needs to be defined by a new subelement of <message-driven> and a new attribute of
@MessageDriven rather than by a new standard activation configuration property. Possible answers are:
* this is needed for consistency with the existing <message-destination-link> and the proposed
<message-destination-jndi-name> subelements of <message-driven>. (See
[JMS_SPEC-54|
http://java.net/jira/browse/JMS_SPEC-54]).
* the connection factory is such an important property of a JMS MDB that it deserves explicit support in the ejb-jar.xml
schema and by the compiler, rather than being relegated to being just an activation property.