JD Edwards – IBM i Java Customization
There are situations where it may be necessary to customize settings for the IBM i Java environment for different JD Edwards EnterpriseOne (JDE E1) JVMs. JD Edwards EnterpriseOne JVMs might include the Server Manager Agent JVM, the E1 enterprise kernel in process JVM, or the JAS web application server JVM.
Why Customize Java Settings
An example customization which you may need to make do for an E1 JVM is to modify the java.security file as described in My Oracle Support (MOS) document 2256869.1. The MOS document describes a case where the Server Manager Console is unable to communicate with the Server Manager Agent and/or Runtime Metrics are not being displayed for a managed instance.
In both cases the core issue is a JDE Java JVM is unable to connect to the SM Console because recent updates to Java have disabled certain TLS algorithms that EnterpriseOne JVMs are dependent on for establishing their secure connection to the SM Console.
The work around for this E1 connection issue, is to customize the JVM settings by editing the java.security file for the specific JDK version being used for the failing JVM. Unfortunately, modifying the system default java.security file as described in the MOS document has a number issues:
- Each time you apply a newer update for the JDK you modified, the java.security file updates you make in the default location (/QOpenSys/QIBM/ProdData/JavaVM/jdkXX/XXbit/…) will be lost as the new update will replace the system default java.security file. IBM does not recommend modifying the JDK system files directly.
- When you have multiple JDK versions being used by different EnterpriseOne processes, then the MOS document would require modifying multiple java.security system files. For example, the SM Agent might be using Java 8 32-bit JDK (/QOpenSys/…/JavaVM/jdk80/32bit/…) while the E1 enterprise kernel in process JVMs might be using Java 7 64-bit JDK (/QOpenSys/…/JavaVM/jdk70/64bit/…).
- Modifying the system default java.security file for the IBM i JDK version means that every JVM using that specific JDK will be impacted. The reason the system default java.security file disables certain TLS algorithms is because those algorithms are no longer considered secure. By editing the java.security file to remove those algorithms, you are allowing those insecure algorithms to be used for not just EnterpriseOne – but for any JVM using that JDK.
IBM Best Practice for Java Customizations
IBM support document N1012992 (How to Customize Java Security Configuration Properties for JDKs on the IBM i) describes how to perform customizations like changes to the java.security file in a way that will avoid the issues above. Basically, instead of editing the system files directly you create a property file that contains only the specific changes you want applied to the system file. Then you tell the JVMs associated with the specific application needing those customizations to apply those changes from your custom file(s) to the system file during JVM initialization.
This means you do NOT need to modify any system files that are owned by the different JDKs under the product directory (/QOpenSys/QIBM/ProdData/JavaVM/…) and thus your changes will not be impacted when future Java updates are applied. Only the JVMs for the specific application you want to use your customizations will be impacted – while other JVMs can continue to run with the system default file settings. Finally, you can have multiple JDK versions use the same custom file – so the same set of customizations can be applied to multiple JDKs (ie. Java 7, Java 8, 32-bit, 64-bit).
Example Implementation for JDE EnterpriseOne
Following example shows how to implement the same customization recommended in the MOS document 2256869.1 without editing the system java.security file directly. We will also show how to apply the same customization to multiple EnterpriseOne JVMs (SM Agent JVM and the enterprise server kernel in process JVM) which are using different JDK versions.
The example here issue commands using QShell which supports unix style commands to work with files in the IBM i integrated file system. To start a QShell environment use the IBM i CL command STRQSH or QSH. You can exit the QShell environment by using either F12 (which leaves the existing QShell environment in tack) or F3 (which ends the existing QShell environment completely). In many cases you can accomplish the same steps using IBM i CL commands instead of using QShell.
First we will create a directory that will hold customization files specific to JDE EnterpriseOne. For example, create the directory “jdePatches”. Then copy the default system file java.security, which we will use as the basis for our customizations, into the directory we just created. Finally, give the copied file a new name to identify it as containing JDE specific customizations – in this case we name it “jde-java.security”.
> mkdir /jdePatches
> cd /jdePatches
> cp /QOpenSys/QIBM/ProdData/JavaVM/jdk80/32bit/jre/lib/security/java.security
> mv java.security jde-java.security
Edit the new file (/jdePatches/jde-java.security) and in this case we want to delete all the lines except the following – which is the one property we want to customize as described in the MOS document.
TIP: Use the edit file (EDTF) command against ‘/jdePatches’ and then use option 2=Edit on the ‘jde-java.security’ file.
Here is what you want the jde-java.security file to look like, basically just the one property for jdk.tls.disabledAlgorithms with the 3DES_EDE_CBC, anon, null algorithms removed from the list versus what is contained in the default system java.security file.
# jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, DESede, \
EC keySize < 224
Passing Java System Properties to JVM
When starting the JDE EnterpriseOne Java processes, you need to specify that the jde-java.security file with the customizations is used to override (append) to the default system java.security file. This is done by setting the following custom property:
java.security.properties=<path to security file>
There are a number of ways to set this custom property when launching each JDE EnterpriseOne Java process or JVM. Here are a couple of the most common.
1. On the Java command using the -D option to set system properties on the invocation of the JVM.
java -Djava.securiy.properties=/jdePatches/jde-java.security JavaProgram
2. Add the property to the SystemDefault.properties file.
NOTE: When a JVM is started the system properties can be loaded from the home directory of the user profile that starts the JVM (/home/<user-profile>/SystemDefault.properties), or globally from the SystemDefault.properties file located in the directory /QIBM/UserData/Java400.
For more details on how to set Java system properties see this link:
Option 1 – Use the Java command line option to explicitly set which JVMs use the custom property. In the case of the SM Agent JVM, this means you will need to edit the runAgent script and add the -D option. For example, your runAgent script in /…/SCFHA/bin/ would be edited so that the Java command invocation looks like this.
$JAVA_HOME$JDKBIN$JAVAEXE -classpath \
com.jdedwards.mgmt.agent.Launcher 2>/dev/null 1>/dev/null &
NOTE: The backslash is required if you want to break the single line into the runAgent script file into multiple lines. By default the runAgent script file shipped by JDE would be all one long line.
If you deploy new updates for the SM Agent to the IBM i, you will potentially have to re-apply these changes to the runAgent script. Which is a downside of making the changes in this manner.
In the case of the EnterpriseOne kernel in process JVMs, command line options are set in the [JDE JVM] section of the JDE.INI file. The DefaultOptions parameter in that section can be used to set -D command line options for the JVM. Your JDE.INI file [JDE JVM] section would look something like this:
# Settings governing the usage of the in-process JVM inside of E1 processes.
The downside of this approach is that you need to modify multiple files to set the command line options for the different JDE JVMs. But you will be sure that only the JDE JVMs are configured to use the specified custom property and that no other JVMs on the system are impacted by the change.
Option 2 - The easiest way to specify the custom property for just the JDE E1 JVMs is to create a SystemDefault.properties file in the home directory of the JDE user profile used to run the JDE JVMs (both SM Agent JVM and enterprise kernel in process JVMs). So if all the EnterpriseOne JVMs are started from the user profile ONEWORLD profile – then create a SystemDefault.properties file in the directory /home/ONEWORLD and set the java.security.properties as shown below.
# append custom JDE E1 java.security file for all JVMs for this user
When there are multiple user profiles that may be used to run the JDE E1 JVMs, you can either create a SystemDefault.properties in the home directory of each different user profile OR create a SystemDefault.properties in the directory /QIBM/UserData/Java400, which will be used for every JVM on the system.
The downside of using the global SystemDefault.properties in this way is that it impacts JVMs that are not associated with JD Edwards.