Define mandatory activation config properties for JMS MDBs

[glassfishrobot]

This is a request for the EJB 3.2 spec to add additional activation configuration properties clientId and subscriptionName for JMS message-driven beans as follows:

Section 5.4 of the EJB 3.1 spec currently defines the the following activation configuration properties for JMS message-driven beans:
acknowledgeMode (optional, default is AUTO_ACKNOWLEDGE)
messageSelector (default is an empty String)
destinationType (optional, no default)
subscriptionDurability (default is NonDurable)

This should be extended to define the following additional activation configuration properties:

clientId
subscriptionName

These property names match those recommended in JCA 1.6.

If set, clientId would be used to set clientId for the connection used by the MDB, and must be unique in accordance with JMS 1.1. There would be no default value. JMS 1.1 states that clientId must be set if a durable subscription is being used. However in JMS 2.0 JMS_SPEC-39 proposes that this requirement would be removed and clientId would always be optional.

If a durable subscription is being used, then JMS requires that subscriptionName be set. In the case of a MDB the subscriptionName is normally given a name unique to the MDB, to distinguish it from other MDBs and other applications subscribed to the same topic. It is therefore proposed that the EJB specification state that if the subscription is durable and subscriptionName is not set then the container will automatically set subscriptionName to the name of the MDB.

As with the existing activation configuration properties for JMS message-driven beans defined in the EJB specification, clientId and subscriptionName could be specified either using the MessageDriven annotation

@MessageDriven(activationConfig =  {
    @ActivationConfigProperty(propertyName = "subscriptionDurability.", propertyValue = "Durable"),
    @ActivationConfigProperty(propertyName = "clientId", propertyValue = "MyMDB"),
    @ActivationConfigProperty(propertyName = "subscriptionName", propertyValue = "MySub")
})

or in ejb-jar.xml:

<ejb-jar>
  <enterprise-beans>
    <message-driven>
      <ejb-name>test.MyMDB</ejb-name>
      <activation-config>
         <activation-config-property>
            <activation-config-property-name>subscriptionDurability</activation-config-property-name>
            <activation-config-property-value>Durable</activation-config-property-value>
         </activation-config-property>
         <activation-config-property>
            <activation-config-property-name>clientId</activation-config-property-name>
            <activation-config-property-value>MyMDB</activation-config-property-value>
         </activation-config-property>
         <activation-config-property>
            <activation-config-property-name>subscriptionName</activation-config-property-name>
            <activation-config-property-value>MySub</activation-config-property-value>
         </activation-config-property>  
      </activation-config>
    </message-driven>
  </enterprise-beans>
</ejb-jar>

Affected Versions

[3.2]

[glassfishrobot]

Reported by @nigeldeakin

[glassfishrobot]

Issue-Links:
blocks
JMS_SPEC-30

[glassfishrobot]

Was assigned to mvatkina

[glassfishrobot]

@nigeldeakin said:
I would suggest amending the following text above:

If a durable subscription is being used, then JMS requires that subscriptionName be set. In the case of a MDB the subscriptionName is normally given a name unique to the MDB, to distinguish it from other MDBs and other applications subscribed to the same topic. It is therefore proposed that the EJB specification state that if the subscription is durable and subscriptionName is not set then the container will automatically set subscriptionName to the name of the MDB.

to this:

If a durable subscription is being used, then JMS requires that subscriptionName be set. In the case of a MDB the subscriptionName is normally given a name unique to the MDB deployment, to distinguish it from other deployments of the same MDB, other MDBs, and other applications subscribed to the same topic. It is therefore proposed that the EJB specification state that if the subscription is durable and subscriptionName is not set then the container will automatically set subscriptionName to a suitable name which uniquely identifies this particular MDB deployment.

[glassfishrobot]

mvatkina said:
See http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2012-07/message/33

[glassfishrobot]

mvatkina said:
Reopening to update the spec for UniqueMDBName. java:comp namespace is shared in a WAR file, so the current thinking is to use a new method on MessageEndpointFactory. When the API is added in JCA MR, EJB spec needs to be updated.

[glassfishrobot]

mvatkina said:
Adjusted to match the latest JMS spec (including subscription scope removal)

[glassfishrobot]

Marked as fixed on Monday, February 25th 2013, 5:27:37 pm

[glassfishrobot]

smarlow said:
Could you please clarify what must happen, if a durable subscription is specified but subscriptionName is not specified? Is the MDB container required to set a unique subscriptionName?

Another question, depending on the response to the above. May the MDB container set a unique subscriptionName, if the subscriptionName is not provided?

Thank you,
Scott

[glassfishrobot]

This issue was imported from java.net JIRA EJB_SPEC-41