Adjust the WebSphere MQ resource adapter configuration when migrating profiles between maintenance level 7.0.0.0 and later levels


 

+

Search Tips   |   Advanced Search

 

When you migrate WAS profiles from maintenance level 7.0.0.0 to later maintenance levels, or from later maintenance levels to the 7.0.0.0 maintenance level, manually adjust the WebSphere MQ resource adapter configuration. The code provided by the WebSphere MQ resource adapter is used by the WebSphere MQ messaging provider, and also by the WebSphere MQ link and WebSphere MQ server features of the default messaging provider.

In profiles created at WAS maintenance level 7.0.0.0, the WebSphere MQ resource adapter binary files are located in each profile. In profiles created at WAS maintenance level 7.0.0.1 or later, these binary files are located in...

APP_ROOT

When you apply maintenance to a WAS V7 installation, the maintenance pack only updates the WebSphere MQ resource adapter binary files in the APP_ROOT directory. This behavior gives rise to the following scenarios:

 

 

If the installation is at maintenance level 7.0.0.1 or later, adjust the profiles that were created at maintenance level 7.0.0.0 so that they use WebSphere MQ resource adapter binary files located in the APP_ROOT directory.

If the WAS installation is at a maintenance level of 7.0.0.1 or later, and contains a profile created at maintenance level 7.0.0.0, adjust the maintenance level 7.0.0.0 profile to use the set of WebSphere MQ resource adapter binary files located in the APP_ROOT directory (which is kept up-to-date by subsequent maintenance packs) rather than the set of WebSphere MQ resource adapter binary files located in the maintenance level 7.0.0.0 profile. Notes:

  1. Start the appserver. If the profile is part of a network deployment configuration, start the dmgr and all node agents. If the profile contains an administrative agent, start the administrative agent.

  2. Copy the following Jython script into a file called convertWMQRA.py, then save it into the $WP_PROFILE/bin directory. 

     
ras = AdminUtilities.convertToList(AdminConfig.list('J2CResourceAdapter'))
 for ra in ras :
   desc = AdminConfig.showAttribute(ra, "description")
   if desc == "WAS 7.0 Built In WebSphere MQ Resource Adapter":
      print "Updating archivePath and classpath of " + ra
      AdminConfig.modify(ra, [['archivePath', "${WAS_INSTALL_ROOT}/installedConnectors/wmq.jmsra.rar"]])
      AdminConfig.unsetAttributes(ra, ['classpath'])
      AdminConfig.modify(ra, [['classpath', "${WAS_INSTALL_ROOT}/installedConnectors/wmq.jmsra.rar"]])
      AdminConfig.save()
   end if
 end for

  3. Use the wsadmin tool to run the Jython script that we have just created.

    Open a command prompt and navigate to the $WP_PROFILE/bin directory, then enter the following command:

    wsadmin -lang jython -f convertWMQRA.py

    If we run the script against a profile that is part of a network deployment configuration, the script updates all profiles that need updating in that configuration.

  4. If running in a network deployment configuration, verify the node agents are fully re-synchronized.

    See Synchronizing nodes with the wsadmin tool or Manage nodes.

  5. Stop all servers in the profile.

    If the profile is part of a network deployment configuration, also stop any cluster members in the configuration, stop all node agents in the configuration, and stop the dmgr.

  6. Run the osgiCfgInit command from the $PROFILE_ROOT/bin directory.

    If the profile is part of a network deployment configuration, run the osgiCfgInit command from the $PROFILE_ROOT/bin directory of every profile that is part of the configuration.

    The osgiCfgInit command resets the class cache used by the OSGi runtime environment.

  7. Restart all servers in the profile.

    If the profile is part of a network deployment configuration, also restart any cluster members in the configuration, restart all node agents in the configuration, and restart the dmgr.

 

Results

The profiles createdd at maintenance level 7.0.0.0 are now configured to use the WebSphere MQ resource adapter binary files that are located in the APP_ROOT directory.

 

If the installation is at maintenance level 7.0.0.1 or later, and you want to remove the maintenance packs so that the installation reverts to maintenance level 7.0.0.0, before you remove the maintenance packs revert the maintenance level 7.0.0.0 profiles that you previously adjusted, so that they again use WebSphere MQ resource adapter binary files located in the profile.

Perform this task under the following circumstances:

Perform this task to revert each previously-adjusted profile so that it again uses WebSphere MQ resource adapter binary files located in the profile.

 

  1. Start the appserver.

    If the profile is part of a network deployment configuration, start the dmgr and all node agents. If the profile contains an administrative agent, start the administrative agent.

  2. Copy the following Jython script into a file called revertWMQRA.py, then save it into the $WP_PROFILE/bin directory. 

     
ras = AdminUtilities.convertToList(AdminConfig.list('J2CResourceAdapter'))
 for ra in ras :
   desc = AdminConfig.showAttribute(ra, "description")
   if desc == "WAS 7.0 Built In WebSphere MQ Resource Adapter":
      print "Updating archivePath and classpath of " + ra
      AdminConfig.modify(ra, [['archivePath', "${CONNECTOR_INSTALL_ROOT}/wmq.jmsra.rar"]])
      AdminConfig.unsetAttributes(ra, ['classpath'])
      AdminConfig.modify(ra, [['classpath', "${CONNECTOR_INSTALL_ROOT}/wmq.jmsra.rar"]])
      AdminConfig.save()
   #end if
#end for

  3. Use the wsadmin tool to run the Jython script that we have just created.

    Open a command prompt and navigate to the $WP_PROFILE/bin directory, then enter the following command:

    wsadmin -lang jython -f revertWMQRA.py

    If we run the script against a profile that is part of a network deployment configuration, the script updates all profiles that need updating in that configuration.

  4. If running in a network deployment configuration, verify the node agents are fully re-synchronized.

    See Synchronizing nodes with the wsadmin tool or Manage nodes.

  5. Stop all servers in the profile.

    If the profile is part of a network deployment configuration, also stop any cluster members in the configuration, stop all node agents in the configuration, and stop the dmgr.

  6. Uninstall WAS maintenance levels from all installations in the configuration, so that each installation is at maintenance level 7.0.0.0.

  7. For each profile created at maintenance level 7.0.0.0 in the configuration:

    1. Navigate to the $WP_PROFILE/installedConnectors/wmq.jmsra.rar directory.

      For example: C:\was7gm1\profiles\AppSrv01\installedConnectors\wmq.jmsra.rar

      If the wmq.jmsra.rar directory does not already exist, create it then navigate to it.

    2. Use the jar command, extract the contents of the APP_ROOT/lib/WMQ/ra/wmq.jmsra.rar file into the directory.

      For example: jar -xvf C:\was7gm1\lib\WMQ\ra\wmq.jmsra.rar

      The wmq.jmsra.rar directory now contains a number of jar files, and a subdirectory called META-INF.

    3. Verify the wmq.jmsra.rar directory and its contents have the appropriate permissions so that they can be read and run by the WAS installation.

  8. Run the osgiCfgInit command from the $PROFILE_ROOT/bin directory.

    If the profile is part of a network deployment configuration, run the osgiCfgInit command from the $PROFILE_ROOT/bin directory of every profile that is part of the configuration.

    The osgiCfgInit command resets the class cache used by the OSGi runtime environment.

  9. Restart all servers in the profile.

    If the profile is part of a network deployment configuration, also restart any cluster members in the configuration, restart all node agents in the configuration, and restart the dmgr.

 

Results

The profiles that you first created at maintenance level 7.0.0.0, then adjusted to work at maintenance level 7.0.0.1 or later, have now been reverted to use the WebSphere MQ resource adapter binary files that are located in each profile.

 

Next steps

If maintenance is subsequently reapplied, so that this installation is again updated to maintenance level 7.0.0.1 or later, repeat the previous task for any profiles that were originally created at maintenance level 7.0.0.0.

 

If the installation is at maintenance level 7.0.0.1 or later, and you want to remove the maintenance packs so that the installation reverts to maintenance level 7.0.0.0, after you remove the maintenance packs adjust the profiles that were created at maintenance level 7.0.0.1 or later, so that they use WebSphere MQ resource adapter binary files copied into the profile.

This task assumes that we have already performed the following tasks:

  1. we have reverted any previously-adjusted maintenance level 7.0.0.0 profiles so that they again use WebSphere MQ resource adapter binary files located in the profile.

  2. we have removed the maintenance packs and reverted the installation to maintenance level 7.0.0.0.
we need not perform this task if the maintenance level, after the maintenance packs have been removed, is later than level 7.0.0.0.

Perform this task under the following circumstances:

Perform this task to adjust the profiles that were created at maintenance level 7.0.0.1 or later, so that they use WebSphere MQ resource adapter binary files copied into the profile.

If we do not perform this task:

 

  1. Open a command prompt and navigate to the $WP_PROFILE/installedConnectors directory.

    For example: C:\was7gm1\profiles\AppSrv01\installedConnectors

  2. Create a subdirectory called wmq.jmsra.rar, then navigate to it.

  3. Use the jar command, extract the contents of the APP_ROOT/lib/WMQ/ra/wmq.jmsra.rar file into the directory.

    For example: jar -xvf C:\was7gm1\lib\WMQ\ra\wmq.jmsra.rar

    The wmq.jmsra.rar directory now contains a number of jar files, and a subdirectory called META-INF.

  4. Verify the wmq.jmsra.rar directory and its contents have the appropriate permissions so that they can be read and run by the WAS installation.

    If the profile is part of a network deployment configuration, repeat this step for every affected profile for the configuration.

  5. Start the appserver.

    If the profile is part of a network deployment configuration, start the dmgr and all node agents. If the profile contains an administrative agent, start the administrative agent.

  6. Copy the following Jython script into a file called convertWMQRA.py, then save it into the $WP_PROFILE/bin directory. 

    ras = AdminUtilities.convertToList(AdminConfig.list('J2CResourceAdapter'))
 for ra in ras :
   desc = AdminConfig.showAttribute(ra, "description")
   if desc == "WAS 7.0.0.1 Built In WebSphere MQ Resource Adapter":
      print "Updating archivePath and classpath of " + ra
      AdminConfig.modify(ra, [['archivePath', "${CONNECTOR_INSTALL_ROOT}/wmq.jmsra.rar"]])
      AdminConfig.unsetAttributes(ra, ['classpath'])
      AdminConfig.modify(ra, [['classpath', "${CONNECTOR_INSTALL_ROOT}/wmq.jmsra.rar"]])
      AdminConfig.save()
   #end if
#end for

  7. Use the wsadmin tool to run the Jython script that we have just created.

    Open a command prompt and navigate to the $WP_PROFILE/bin directory, then enter the following command:

    wsadmin -lang jython -f convertWMQRA.py

    If we run the script against a profile that is part of a network deployment configuration, the script updates all profiles that need updating in that configuration.

  8. If running in a network deployment configuration, verify the node agents are fully re-synchronized.

    See Synchronizing nodes with the wsadmin tool or Manage nodes.

  9. Stop all servers in the profile.

    If the profile is part of a network deployment configuration, also stop any cluster members in the configuration, stop all node agents in the configuration, and stop the dmgr.

  10. Run the osgiCfgInit command from the $PROFILE_ROOT/bin directory.

    If the profile is part of a network deployment configuration, run the osgiCfgInit command from the $PROFILE_ROOT/bin directory of every profile that is part of the configuration.

    The osgiCfgInit command resets the class cache used by the OSGi runtime environment.

  11. Restart all servers in the profile.

    If the profile is part of a network deployment configuration, also restart any cluster members in the configuration, restart all node agents in the configuration, and restart the dmgr.

 

Results

The profiles createdd at maintenance level 7.0.0.1 or later are now configured to use WebSphere MQ resource adapter binary files copied into each profile.

 

If maintenance is reapplied so that an installation that had reverted to maintenance level 7.0.0.0 is again at maintenance level 7.0.0.1 or later, revert the maintenance level 7.0.0.1 or later profiles that you previously adjusted, so that they again use WebSphere MQ resource adapter binary files located in the APP_ROOT directory.

Perform this task under the following circumstances:

Perform this task to revert each previously-adjusted profile so that it again uses WebSphere MQ resource adapter binary files located in the APP_ROOT directory.

 

  1. Start the appserver.

    If the profile is part of a network deployment configuration, start the dmgr and all node agents. If the profile contains an administrative agent, start the administrative agent.

  2. Copy the following Jython script into a file called revertWMQRA.py, then save it into the $WP_PROFILE/bin directory. 

    ras = AdminUtilities.convertToList(AdminConfig.list('J2CResourceAdapter'))
 for ra in ras :
   desc = AdminConfig.showAttribute(ra, "description")
   if desc == "WAS 7.0.0.1 Built In WebSphere MQ Resource Adapter":
      print "Updating archivePath and classpath of " + ra
      AdminConfig.modify(ra, [['archivePath', "${WAS_INSTALL_ROOT}/installedConnectors/wmq.jmsra.rar"]])
      AdminConfig.unsetAttributes(ra, ['classpath'])
      AdminConfig.modify(ra, [['classpath', "${WAS_INSTALL_ROOT}/installedConnectors/wmq.jmsra.rar"]])
      AdminConfig.save()
   #end if
#end for

  3. Use the wsadmin tool to run the Jython script that we have just created.

    Open a command prompt and navigate to the $WP_PROFILE/bin directory, then enter the following command:

    wsadmin -lang jython -f revertWMQRA.py

    If we run the script against a profile that is part of a network deployment configuration, the script updates all profiles that need updating in that configuration.

  4. If running in a network deployment configuration, verify the node agents are fully re-synchronized.

    See Synchronizing nodes with the wsadmin tool or Manage nodes.

  5. Stop all servers in the profile.

    If the profile is part of a network deployment configuration, also stop any cluster members in the configuration, stop all node agents in the configuration, and stop the dmgr.

  6. Run the osgiCfgInit command from the $PROFILE_ROOT/bin directory.

    If the profile is part of a network deployment configuration, run the osgiCfgInit command from the $PROFILE_ROOT/bin directory of every profile that is part of the configuration.

    The osgiCfgInit command resets the class cache used by the OSGi runtime environment.

  7. Restart all servers in the profile.

    If the profile is part of a network deployment configuration, also restart any cluster members in the configuration, restart all node agents in the configuration, and restart the dmgr.

 

Results

The profiles that you first created at maintenance level 7.0.0.1 or later, then adjusted to work at maintenance level 7.0.0.0, have now been reverted to use the WebSphere MQ resource adapter binary files that are located in the APP_ROOT directory.

 

Next steps

Profiles that are first created at maintenance level 7.0.0.1 or later do not have WebSphere MQ resource adapter binary files within the profile, unless you adjust them to work at maintenance level 7.0.0.0. Now that we have reverted these adjusted profiles to again use the WebSphere MQ resource adapter binary files in the APP_ROOT directory, we can delete the copy of the binary files from within each of these profiles - provided that the profile-based copy of the binary files is no longer being used by any appserver process.

 

Related tasks

Troubleshooting messaging

 

Related


Messaging troubleshooting tips