DevOps Automation

 View Only

Tips & Tricks - Replacing the JRE for DevOps Test Products

By Jerry Shengulette posted Mon November 20, 2023 07:15 PM

  

Replacing JRE for DevOps Test Products

(with non-Semeru JRE)

Support Caveat

Each release of the DevOps Test products is subject to extensive functional and system testing prior to its general availability. That testing uses the most recently available stable version of IBM Semeru Runtime Open Edition Java. The frequency of Java updates makes it logistically impossible to step back and retest with every subsequent update. Therefore, the version used during the testing cycle is the only version that is explicitly supported, and it is not recommended to use a different version.

In situations where policies require updating the Java version, it is possible to do so. It is unlikely, but possible, that the change to a newer build of Java will cause problems. Therefore, if Java is updated, and an unusual problem is encountered, product support might request that the issue is reproduced on the supported Java build prior to any investigation.

Issue

The DevOps Test products (DevOps Test Performance, DevOps Test UI, DevOps Test Integrations and APIs) ship with their own Java Runtime Environment (JRE).  Each product is designed and tested to use this JRE in its features. We have run into at least two circumstances where this shipped JRE has proven problematic:

  1. Security scans performed in a customer environment might flag the Java that ships with the product as being “too old”/unsecure. The supported resolution would be to upgrade the DevOps Test product. Newer versions tend to ship with newer JREs. “Tend to” is used because, for example, v10.5.2 and v10.5.3 ship with the same JRE.
  2. Security policies in place may not allow the product JRE to execute. We generically refer to this as a “deny list entry” but the exact mechanism for accomplishing this can vary from lab to lab. The support team does not delve into figuring out customer configurations in this area. The supported resolution would be to add the shipped JRE to the “allow list”, through whatever means are appropriate for the individual environment.

Limitations

There are use cases for which JRE replacement will not work:

  • If you are using the Response Time Breakdown feature with DevOps Test Performance.
  • … (The ellipsis represents that this is not an all-inclusive list.)

Prerequisite JRE Setup

It is required to have an existing JRE in place. Most commonly this a 64-bit version of the Oracle Sun JRE. By default, it would be located at C:\Program Files\Java\jre1.8.0_abc\, where “abc” is the Java 8 update level. This is the JRE used in the examples. Instructions for installing a JRE are not included here; most are proprietary and there would be no way of keeping them up-to-date accurately.

Make Backups

If you have any combination of DTP/DTUI/DTP Agent installed together in a shell-shared environment, the products share the JRE. In this scenario, you would only need to back up the JRE once.

DevOpts Test UI

When DTUI is not running, go to the installation directory and rename the existing jre directory in the DevOpsTest directory. Administrator privilege may be required to do this.  For example, C:\Program Files\IBM\DevOpsTest\jdk\jre to C:\Program Files\IBM\DevOpsTest\jdk\jre-ORIGINAL.

DevOps Test Performance

When DTP is not running, go to the installation directory and rename the existing jre directory in the DevOpsTest directory. Administrator privilege may be required to do this.  For example, C:\Program Files\IBM\DevOpsTest\jdk\jre to C:\Program Files\IBM\DevOpsTest\jdk\jre-ORIGINAL.

DevOps Test Performance Agent

Stop the MajordomoService service. Rename the existing jre directory in the DevOpsTest directory. Administrator privilege may be required to do this.  For example, C:\Program Files\IBM\DevOpsTest\jdk\jre to C:\Program Files\IBM\DevOpsTest\jdk\jre-ORIGINAL.

DevOps Test Integrations and APIs

When product is not running, go to the installation directory and rename the existing jre directories. Administrator privilege may be required to do this.

DTAPI:

C:\Program Files\IBM\DevOpsTestAPI\jre to C:\Program Files\IBM\DevOpsTestAPI\jre-ORIGINAL

DTAPI-Agent:

C:\Program Files\IBM\DevOpsTestAPIAgent\jre to C:\Program Files\IBM\DevOpsTestAPIAgent\jre-ORIGINAL

DT Control Panel:

C:\Program Files\IBM\DevOpsTestControlPanel\jre to C:\Program Files\IBM\DevOpsTestControlPanel\jre-ORIGINAL

Deploy

Start a Windows Command Prompt as Administrator and use the mklink command to create the junction directories for DevOpsTest jdk.

DTUI and DTP and DTP Agent:

mklink /J "C:\Program Files\IBM\DevOpsTest\jdk\jre" "C:\Program Files\Java\jre1.8.0_<updatelevel>"

DTAPI:

mklink /J "C:\Program Files\IBM\DevOpsTestAPI\jre" " C:\Program Files\Java\jre1.8.0_<updatelevel>"

DTP-Agent:

mklink /J "C:\Program Files\IBM\DevOpsTestAPIAgent\jre" " C:\Program Files\Java\jre1.8.0_<updatelevel>"

DT Control Panel and HTTP Proxy:

mklink /J " C:\Program Files\IBM\DevOpsTestControlPanel\jre " " C:\Program Files\Java\jre1.8.0_<updatelevel>"

To validate that the mklink commands worked as desired:

  1. Open a DOS command window.
  2. Navigate to directory in which you created the soft link (the first argument to the mklink)
  3. Run this command:  .\java -version

The result should be version information for the global JRE, similar to this:

Command Window Displaying .\java -version

Eclipse Modifications

The Eclipse-based products (DTUI and DTP) start a java virtual machine (JVM) when opened from the user interface. The path to this JVM must be changed with the transition to a new JRE.

  1. Open Windows File Explorer.
  2. Navigate to C:\Program Files\IBM\DevOpsTest\.
  3. Make a backup copy of the existing eclipse.ini file.
  4. Use your favorite text editor to edit eclipse.ini.
  5. The top two lines of the file should look something like this:
    -vm
    jdk/jre/bin/j9vm/jvm.dll
  6. The “j9vm” directory does not exist in the Oracle Sun JRE. Change the 2nd line to:
    jdk/jre/bin/server/jvm.dll
  7. Save the file.

Closing Caveat

If there is a need to remove the original jdk and jre directories to satisfy the security scan, it is strongly recommended to first create a remote back-up or archive so that the original version can be restored without re-installing. As mentioned earlier, this new configuration is not officially supported; any troubleshooting exercise might include a request to revert to the original configuration.

 

0 comments
37 views

Permalink