adminobject elements to define destinations and naming contexts for inbound and outbound communication:A context object for an administered object is used to look up queues and topics dynamically using automatic destination wrapping, which is described in Using Automatic Destination Wrapping.
Automatic destination wrapping allows applications to bind an administered object in the application server's JNDI tree that represents a WebLogic JNDI context. Applications can then look up this WebLogic JNDI context to look up JMS destinations by their name in the WebLogic JNDI tree. This can simplify the configuration for applications that have a large number of destinations because only one administered object must be configured with the application server.
Use the following elements to define a context object for an administered object:
<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 object for the administered object. You specify this using the following syntax:
connector:<connectorName>/
The macros defined in a groupDefinition may be used for the value of connector in this property value. For example, you can use connector:{connectorName}/ in place of connector:wlDevelopment/ when the value of the macro {connectorName} within a group is wlDevelopment. For more information, see Advanced Method for Configuring Resource Providers.
Automatic destination wrapping allows an administered object to automatically wrap provider destinations, eliminating the need to create an administered object for each provider destination and explicitly binding the administered object to the destination's JNDI. A single administered object 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 resource adapter administered objects bound in JNDI. These administered objects may represent JMS destinations or a destination context. When used for JMS destinations, you must defined one administered object for each JMS destination. If an applications uses 20 JMS destinations, then you must configure 20 individual administered objects, one for each destination. Applications must also define and map these 20 JMS destinations in their Java EE descriptors as resource-env-references.
The destination context administered object allows you to integrate a single destination context, which in turn may be used to lookup any number of JMS destinations at the WebLogic Server instance serving as the JMS provider. Applications need to define only 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 deployment time. For example, the JMS resource adapter gets the source and target destinations from end users only at runtime.
If your application needs to access a large number of destinations. This avoids the need to configure a matching set of JMS resource adapter destinations for all destinations of a resource provider. Otherwise, each resource provider destination has to be mapped to a configured administered object before it can be used by the application.
For example, an administered object 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>
. . .
In the preceding example, rp_name represents the name of the resource provider defined in the ra.xml file. For more information, see Administered Object Configuration Properties.
In the application, look up myContext as a javax.naming.Context:
. . .
@Resource(mappedName="myContext")
private javax.naming.Context wljmsraContext;
. . .
Then you can look up the queue destinations using the following context:
. . .
Queue theMdbQueue = (Queue) wlraContext.lookup("com.oracle.jms.qa.myQ1");
. . .
You can create the following type of administered objects for JMS queues and topics:
For queues, you create an instance of a <adminobject-class> object: oracle.j2ee.ra.jms.generic.WLQueueAdmin
For topics, you create an instance of a <adminobject-class> object: oracle.j2ee.ra.jms.generic.WLTopicAdmin
You can create the following administered object 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>
. . .