Our systems guys want to upgrade JAVA used by ALM 15, will that be a problem?

Question ID: 109690

We have been warned by our systems guys that the organization wants to upgrade the version of JAVA on our ALM 15 server.  Will this cause any problems with how ALM works?

Marked as spam
Posted by (Questions: 74, Answers: 4)
Asked on July 21, 2020 12:48 pm
Answers (1)
Private answer

Starting with ALM/QC 12.6, customers need to pre-install JAVA before installing ALM/QC.  Many customers use the Oracle JAVA 8, which works fine, but by default, it installs itself to a folder containing the version/build#.  If JAVA updates itself or if someone blindly updates it without looking into ramifications, ALM/QC will fail to work.

When Oracle JAVA updates itself, it installs to a new folder with the NEW version/build# AND often deletes the previous version.

IF you are running ALM/QC as HTTPS or are using SQL-Server over HTTPS/TLS, your certs are likely stored in "cacerts" under the JAVA folder structure and would be wiped out along with JAVA.

Due to these problems, it is not recommended to randomly upgrade JAVA.  If you MUST, you can change to ALM/QC environment variable "MICRO_FOCUS_JAVA_PATH", which for an ORACLE JAVA 8 may have a path like: "C:Program FilesJavajre1.8.0_181" (look at your current one).

Before upgrading JAVA, also look to see if you have any HTTPS/certs with the clues like 1) QC/ALM uses HTTPS instead of HTTP, 2) SQL-Server uses HTTPS, SSL, TLS (DB Connect string includes clauses like: "EncryptionMethod=SSL;CryptoProtocolVersion=TLSv1.2", 3) You are using LDAPS for ALM user authentication.

Backup any "cacerts" files and take note of original path.  If using ALM/QC over HTTPS, look in <deployment path>serverconf  (example: "C:ProgramDataHPALMserverconf") file jetty-ssl.xml for the tag called (Set name="KeyStorePath"), it will have the path and name of the keystore that contains the cert for ALM over HTTPS (or SQL-server, LDAPS).  Backup this keystore and place into new relative path after updating JAVA.  This path in jetty-ssl.xml will need to change when JAVA updates too.

Again, there are a few EXPLICIT paths pointing to original JAVA path will cause ALM to break (not load up server) -- especially when using HTTPS for ALM and/or SQL-Server.

This is the danger of allowing JAVA to be upgraded -- the followup required to change paths related to JAVA used by ALM/QC.

If you are NOT using any HTTPS/TLS settings for QC/ALM or SQL-Server, then all that you need to change is the MICRO_FOCUS_JAVA_PATH environment variable and cycle ALM service.

Marked as spam
Posted by (Questions: 3, Answers: 466)
Answered on July 21, 2020 12:53 pm