WebSphere MQ custom properties

 

+

Search Tips   |   Advanced Search

 

WAS supports the use of custom properties to define WebSphere MQ properties. This is useful because it enables WAS to work with later versions of WebSphere MQ which might have properties that are not exposed in the console.

In WAS, V6.1, the custom properties that you define are validated by the WebSphere MQ client jar files contained in WAS. In previous versions, this was done within WAS itself, and then by the WebSphere MQ client jar files. If you have defined a property that is not valid for WebSphere MQ, the WebSphere MQ client jar files create an exception, which is caught by WAS, and logged in...

Examples of error messages are given at the end of this topic.

When a later version of WebSphere MQ is available that is supported by the WAS installation, new MQ properties might be created that are not known to WAS. You can configure these as custom properties through WAS so that they are recognized by the WebSphere MQ client jars.

You can also configure WAS to point to the WebSphere MQ client jars in the external JMS provider.

For information on valid values for WebSphere MQ properties, refer to WebSphere MQ Using Java or WebSphere MQ System Administration, which are available from the IBM Publications Center.

The following scenarios illustrate how different cell configurations might be affected.

 

Mixed node scenario

In this scenario, a cell consists of a WAS, Version 6.1 deployment manager and four nodes.

Two of the nodes are WAS, V6.1 and two are WAS, V6.0.

If a WebSphere MQ connection factory is defined at cell level and has custom properties defined which exploit the new fields available in WebSphere MQ, V6, then the connection factory is only bound into the WAS cells that are at V6.1 level. The WAS, V6.0 nodes do not know about the new WebSphere MQ properties and do not bind into the JNDI.

The enhancements made to WAS, V6.1 allow validation of the properties to be deferred to the WebSphere MQ client jars.

Mixed node scenario:


 

Future version of WebSphere MQ scenario

In this scenario a cell consists of WAS, V6.1 deployment manager and nodes.

The WebSphere MQ messaging provider is running at a level later than V6.

WAS is using the default WebSphere MQ client jars shipped with WAS, which are V6.

In this scenario the WebSphere MQ client jars are not aware of the new WebSphere MQ properties so the validation fails and the connection factory does not bind into the JNDI.

Future version of WebSphere MQ scenario


 

Correctly configured scenario

In this scenario, which is similar to the previous one, a cell consists of WAS, V6.1 deployment manager and nodes.

The WebSphere MQ messaging provider is running at a level later than V6.

To successfully use the new WebSphere MQ properties it is necessary to configure the WAS to point to the WebSphere MQ client jars associated with the future version of WebSphere MQ.

Correctly configured scenario


 

Error message example

The following example shows the type of text that the exception created by the client jars contains:

[09/02/06 15:40:06:377 GMT] 0000000a ContainerImpl E   WSVR0501E: Error creating component null [class com.ibm.ws.runtime.component.ApplicationServerImpl] com.ibm.ws.exception.RuntimeWarning: com.ibm.ws.runtime.component.binder.
ResourceBindingException: invalid configuration passed to resource binding logic.
REASON: Failed to create connection factory: Error raised constructing AdminObject, error code: XAQCF PropertyName : XAQCF PropertyName

where PropertyName is the name of the invalid property.


 

Related tasks


Configure custom properties for the WebSphere MQ messaging provider