Use JMS 2.0 ConnectionFactory and Destination Lookup properties

In WebSphere Application Server traditional Version 9.0, the ConnectionFactoryLookup and DestinationLookup properties of an activation specification can be provided with a JNDI name of an administered object to be used in preference to the other activation specification properties.

The JMS 2.0 specification specifies two additional properties on the activation specification used to drive message-driven beans (MDBs). Previously, each vendor had to specify custom properties on the activation specification to provide details that are required to connect to a messaging system and to define which destination to get messages from.

The now standard connectionFactoryLookup and destinationLookup properties can be used to give a JNDI name of the relevant object to look up and use. Within WebSphere Application Server traditional Version 9.0 an IBM MQ Version 9.0 resource adapter is pre-installed.

The following steps show how to customize and use these two properties using the WebSphere Application Server traditional administrative console.

Procedure

First create the objects in JNDI.

1. Create the ConnectionFactory in JNDI as normal (see Configure JMS resources using the administrative console).
2. Create the Destination in JNDI as normal (see Configure JMS resources using the administrative console). The Destination object must have the correct values.
3. Create the activation specification using any values that are needed (see Configure JMS resources using the administrative console). We can create the activation specification with exactly the properties that you need. However, you should bear in mind the following considerations:
   • If you want the IBM MQ resource adapter to use the Java EE connection factory and destination lookup properties, it is less relevant what properties are used when you create the activation specification (see ActivationSpec ConnectionFactoryLookup and DestinationLookup properties.
   • However, any property that is not already defined on either the connection factory or the destination must still be specified on the activation specification. Therefore, you must define the connection consumer properties and additional properties, and the authentication information that is used when a connection is actually created.
   • Of the properties that are defined on the connection factory, the ClientID property has special processing. This is because a common scenario is using a single connection factory with multiple activation specifications. This simplifies administration, however the JMS specification does demand unique client ids, hence the activation specification needs to have the ability to override any value set on the ConnectionFactory. If no ClientID is set on the activation specification, any value on the connection factory is used.

Either update the activation specification that we have created with the two new custom properties by using the WebSphere Application Server administrative console as described in step 4, or use annotations instead as described in step 5.

4. Update the activation specification in the WebSphere Application Server administrative console. These two properties need to be set on the custom properties panel of the activation specification. These properties are not present in the main activation specification panels or on the Activation Specification creation wizard.
   1. Select the activation specification from the list displayed in the Activation specification collection form. The details for the activation specification are displayed in the IBM MQ messaging provider activation specification settings form.
   2. On the IBM MQ messaging provider activation specification settings form, click Custom properties. The Custom properties form is displayed.
   3. On the Custom properties form, create two new custom properties, both of type java.lang.String. In each case, click New and then enter the following details for the custom property:

      Name

      The name of the custom property, either connectionFactoryLookup or destinationLookup.

      Value

      The value for the custom property. You could use the JNDI names in the Value field , for example QuoteCF and QuoteQ.

      Type

      The type of the custom property. Select the custom property type from the list, which in this case must be java.lang.String.

   The deployed MDB will now use these values to create the connection factory and destination. When deploying the MDB, there is no requirement to set the JNDI value configuration.
5. Use annotations instead of the activation specification. It is possible to use annotations in the MDB code to specify values as well. For example, using the JNDI names QuoteCF and QuoteQ, this is what the code would look like:

   @MessageDriven(activationConfig = {       
           @ActivationConfigProperty(propertyName =  "destinationType" , propertyValue =  "javax.jms.Topic" ),       
           @ActivationConfigProperty(propertyName =  "destinationLookup" , propertyValue =  "QuoteQ" ),       
           @ActivationConfigProperty(propertyName =  "connectionFactoryLookup" , propertyValue =  "QuoteCF" )}, mappedName =  "LookupMDB" )
           @TransactionAttribute(TransactionAttributeType.REQUIRED)
           @TransactionManagement(TransactionManagementType.CONTAINER)
           publicclass LookupMDB implements MessageListener {