ejb-spec
  1. ejb-spec
  2. EJB_SPEC-41

Define mandatory activation config properties for JMS MDBs

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 3.2
    • Fix Version/s: 3.2
    • Labels:
      None

      Description

      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>
      

        Issue Links

          Activity

          Hide
          Nigel Deakin added a comment -

          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.

          Show
          Nigel Deakin added a comment - 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.
          Show
          marina vatkina added a comment - See http://java.net/projects/ejb-spec/lists/jsr345-experts/archive/2012-07/message/33
          Hide
          marina vatkina added a comment -

          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.

          Show
          marina vatkina added a comment - 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.
          Hide
          marina vatkina added a comment -

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

          Show
          marina vatkina added a comment - Adjusted to match the latest JMS spec (including subscription scope removal)
          Hide
          smarlow added a comment -

          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

          Show
          smarlow added a comment - 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

            People

            • Assignee:
              marina vatkina
              Reporter:
              Nigel Deakin
            • Votes:
              5 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: