7 Configuring Destinations and Naming Contexts

This chapter provides information on configuring adminobject elements to define destinations and naming contexts for inbound and outbound communication.

This chapter includes the following sections:

Context adminobject Objects

Context adminobjects are used to look up queues and topics dynamically using Automatic Destination Wrapping. See Using Automatic Destination Wrapping.

Auto-Destination Wrapping allows applications to bind an <admin-object> in the application server's JNDI that represents a WebLogic JNDI context. Applications can then lookup this WebLogic JNDI context to lookup JMS destinations by their name in the WebLogic JNDI. This can simplify configuration for applications with a large number of destinations because only one <admin-object> has to be configured with the application-server.

Use the following elements to define a context adminobject:

  • <adminobject-interface>: Use weblogic.jms.ra.WLDestinationContextInterface

  • <adminobject-class>: Use weblogic.jms.ra.WLDestinationContext.

Use the following configuration properties in the <config-property> element:

  • group: The name of the group to associate with this adminobject definition.

  • rpContextLocation: Provides information to the resource adapter describing how to look up JMS destinations using the context admin-object. This will be in the form connector:<connectorName>/.

The macros defined in a groupDefinition may be used for the value of connector in this property value. For instance, connector:{connectorName}/ can be used in place of connector:wlDevelopment/ when the value of the macro {connectorName} is wlDevelopment within a group. See Advanced Resource Provider Configuration using groupDefinitions.

Using Automatic Destination Wrapping

Automatic Destination Wrapping allows an administered object to automatically wrap provider destinations, alleviating the need to create an administered object for each provider destination and explicitly binding the administered object to the destination's JNDI. A single adminobject is defined for each resource provider allowing you to dynamically construct JNDI url's to access each destination within this context.

Applications look up JMS RA admin-objects bound in JNDI. These admin-objects may represent JMS destinations or a destination context. When used for JMS destinations, you must defined one admin-object for each JMS destination. If an applications uses 20 JMS destinations, then you must configure 20 individual admin-objects, one for each destination. Applications must also define and map these 20 JMS destinations in their JEE descriptors as resource-env-references.

The destination context admin-object allows you to integrate a single destination context that in turn, may be used to lookup any number of JMS destinations at the WebLogic Server serving as the JMS provider. Applications only need to define one resource-env-ref mapping for the destination context. Applications lookup the destination context and append the remote WebLogic JNDI name for the destination.

Automatic Destination Wrapping simplifies configuration when:

  • You cannot determine the WebLogic Server JMS destinations at the deployment time. For example, the JMS RA only gets the source and target destinations from end users at runtime.

  • If your application needs to access a large number of destinations. This avoids the need to configure a matching set of JMS RA destinations for all destinations of a resource provider. Otherwise, each resource provider destination has to be mapped to a configured adminobject before it can be used by the application.

For example, an adminobject representing a WebLogic JMS server is bound to JNDI name myContext in foreign application server. If a WebLogic JMS destination with JNDI name jms/bar configured in this WebLogic server JNDI tree, Automatic Destination Wrapping uses myContext/jms/bar in the foreign server JNDI lookup.

The following is an example for automatic wrapping of queues.

. . .
<adminobject-config location="myContext">
   <adminobject-class>weblogic.jms.ra.WLDestinationContext</adminobject-class>
   <config-property name="group" value="wls"/>
   <config-property name="rpContextLocation" value="connector:{rp_name}/"/>
</adminobject-config> 
. . .

where rp_name is the name of the resource provider defined in ra.xml file. See JMS RA adminobject Configuration Properties.

In the application, look up myContext as a javax.naming.Context:

. . .
@Resource(mappedName="myContext")
private javax.naming.Context wljmsraContext;
. . .

Now you can look up the queue destinations using this context:

. . .
Queue theMdbQueue = (Queue) wlraContext.lookup("com.oracle.jms.qa.myQ1");
. . .

Destination adminobjects

There are two types of adminobject objects which can be created for JMS queues and topics:

  • For Queues, the <adminobject-class>: oracle.j2ee.ra.jms.generic.WLQueueAdmin

  • For Topics, the <adminobject-class>: oracle.j2ee.ra.jms.generic.WLTopicAdmin

Example adminobject Stanza

. . .
<!-- Context admin object -->
<adminobject>
   <adminobject-interface>weblogic.jms.ra.WLDestinationContextInterface</adminobject-interface>
   <adminobject-class>weblogic.jms.ra.WLDestinationContext</adminobject-class>
   <config-property>
      <config-property-name>group</config-property-name>
      <config-property-type>java.lang.String</config-property-type>
      <config-property-value></config-property-value>
   </config-property>
   <config-property>
      <config-property-name>rpContextLocation</config-property-name>
      <config-property-type>java.lang.String</config-property-type>
      <config-property-value></config-property-value>
   </config-property>
<adminobject>

<!-- Queue admin object -->
<adminobject>
   <adminobject-interface>weblogic.jms.ra.WLQueueAdminInterface</adminobject-interface>
   <adminobject-class>weblogic.jms.ra.WLQueueAdmin</adminobject-class>
   <config-property>
      <config-property-name>group</config-property-name>
      <config-property-type>java.lang.String</config-property-type>
      <config-property-value></config-property-value>
   </config-property>
   <<config-property>
      <config-property-name>rpResourceLocation</config-property-name>
      <config-property-type>java.lang.String</config-property-type>
      <config-property-value></config-property-value>
   </config-property>
</adminobject>

<!-- Topic admin object -->
<adminobject>
   <adminobject-interface>weblogic.jms.ra.WLTopicAdminInterface</adminobject-interface>
   <adminobject-class>weblogic.jms.ra.WLTopicAdmin</adminobject-class>
   <config-property>
      <config-property-name>group</config-property-name>
      <config-property-type>java.lang.String</config-property-type>
      <config-property-value></config-property-value>
   </config-property>
   <config-property>
      <config-property-name>rpResourceLocation</config-property-name>
      <config-property-type>java.lang.String</config-property-type>
      <config-property-value></config-property-value>
   </config-property>
</adminobject>
. . .