Documentum – DARs installation fails Java 11

As you probably heard if you weren’t in an underground bunker for the past 2 years, Oracle changed the licensing of the Oracle JDK. If you want to read more about it, there is a good FAQ here. This obviously had some important repercussions everywhere and Documentum wasn’t exempted. I would have a lot to say about the way OpenText tried to adapt since Documentum 16.4 (and kind of failed) but that’s not really the topic of this blog. Because of this change on Oracle side, many applications started to support the OpenJDK and move from Java 8 to Java 11 or above. In this blog, I wanted to talk about the issue that you will face if you ever try to install DARs using Java 11.

The support for Java 11 has been introduced with Documentum 16.4, either Oracle JDK or OpenJDK. However, by default, the CS 16.4 still included an Oracle JDK 1.8u152 ($DOCUMENTUM/java64/JAVA_LINK) and if you were to try to use Java 11 with the CS 16.4, you would face & see some “funny” things. In a previous blog, I showed how it was possible to deploy DARs using a simple script and I have been using this for years without problem or rather that is until the use of Java 11. In this blog, I will use a Documentum 20.2 environment installed and configured to use an external OpenJDK 11.0.7 (not pre-packaged with the binaries).

Running the usual script to install some DARs with Java 11 ends-up with the following:

[dmadmin@cs-0 scripts]$ java -version
openjdk version "11.0.7" 2020-04-14
OpenJDK Runtime Environment 18.9 (build 11.0.7+10)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.7+10, mixed mode)
[dmadmin@cs-0 scripts]$
[dmadmin@cs-0 scripts]$ cat deploy-all.sh
#!/bin/bash
docbases="GR_REPO1"
dar_list="D2-DAR.dar"
username="dmadmin"
dar_location="$DM_HOME/install/DARsInternal"
password="xxx"

old_ifs=${IFS}
for docbase in ${docbases}; do
  IFS=','; for dar in ${dar_list}; do
    dar_name=${dar##*/}

    echo "Deploying ${dar_name} into ${docbase}"
    ts=$(date "+%Y%m%d-%H%M%S")

    $JAVA_HOME/bin/java -Ddar="${dar_location}/${dar}" 
        -Dlogpath="${dar_location}/dar-deploy-${dar_name}-${docbase}-${ts}.log" 
        -Ddocbase=${docbase} -Duser=${username} -Ddomain= -Dpassword="${password}" 
        -cp $DM_HOME/install/composer/ComposerHeadless/startup.jar 
        org.eclipse.core.launcher.Main 
        -data $DM_HOME/install/composer/workspace 
        -application org.eclipse.ant.core.antRunner 
        -buildfile $DM_HOME/install/composer/deploy.xml

    if [[ ${?} != 0 ]]; then
      echo "ERROR - There was an error while installing the DAR '${dar_name}' into '${docbase}'"
      exit 1
    fi
  done
done
IFS=${old_ifs}
[dmadmin@cs-0 scripts]$
[dmadmin@cs-0 scripts]$ . ./deploy-all.sh
Deploying D2-DAR.dar into GR_REPO1
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.eclipse.osgi.internal.baseadaptor.BaseStorage (file:$DM_HOME/install/composer/ComposerHeadless/plugins/org.eclipse.osgi_3.8.1.v20120830-144521.jar) to method java.net.URLClassLoader.addURL(java.net.URL)
WARNING: Please consider reporting this to the maintainers of org.eclipse.osgi.internal.baseadaptor.BaseStorage
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
An error has occurred. See the log file
$DM_HOME/install/composer/ComposerHeadless/configuration/1593386605194.log.
ERROR - There was an error while installing the DAR 'D2-DAR.dar' into 'GR_REPO1'
[dmadmin@cs-0 scripts]$

Ignore the “WARNING” messages above, it is something that was added in Java 9 and if you want to read more about it, you can check this post. As you can see, the script fails and give you back a nice log file with 5 000+ lines full of strange messages and errors like:

!ENTRY org.eclipse.equinox.simpleconfigurator 4 0 2020-06-28 23:23:25.599
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: The bundle "org.eclipse.equinox.simpleconfigurator_1.0.301.v20120828-033635 [1]" could not be resolved. Reason: Missing Constraint: Bundle-RequiredExecutionEnvironment: CDC-1.1/Foundation-1.1,J2SE-1.4
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1332)
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1316)
        at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323)
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:390)
        at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)

!ENTRY org.eclipse.equinox.common 4 0 2020-06-28 23:23:25.602
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: The bundle "org.eclipse.equinox.common_3.6.100.v20120522-1841 [59]" could not be resolved. Reason: Missing Constraint: Bundle-RequiredExecutionEnvironment: CDC-1.1/Foundation-1.1,J2SE-1.4
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1332)
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1316)
        at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:323)
        at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:390)
        at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438)
        at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1)
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)

...

!ENTRY org.eclipse.osgi 4 0 2020-06-28 23:23:25.895
!MESSAGE Application error
!STACK 1
java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini).
        at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:74)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
        at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
        at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
        at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
        at org.eclipse.equinox.launcher.Main.main(Main.java:1414)
        at org.eclipse.core.launcher.Main.main(Main.java:34)

What happen is that to deploy DARs, the script is using the Composer Headless. It is a very old software that is present since the creation of the universe (almost) and it doesn’t support Java 11 at all. With Documentum 16.4, since an Oracle JDK 8u152 was shipped with the binaries, it wasn’t an issue to deploy DARs. However, with newer version of the Content Server like 20.2, you can technically install Documentum from scratch using an external Java 11. That being said, since the InstallAnywhere packages (as far as I know) and the Composer Headless do not support Java 11, OpenText included some old JDK 8 here and there to do the needed jobs.

In 20.2 for example, you will find an Oracle JDK 8u202 inside the Composer Headless for DAR installation. Documentum uses this whenever a DAR install is needed: Repository, D2, BPM/xCP, aso… You can find the information about the Oracle JDK 8 in the dardeployer.ini configuration file:

[dmadmin@cs-0 scripts]$ cat $DM_HOME/install/composer/ComposerHeadless/dardeployer.ini
-vm
$DM_HOME/install/composer/ComposerHeadless/java/jdk1.8.0_202_x64/bin
-vm
./java/jdk1.8.0_202_x64/bin
-configuration
darinstallerconfiguration
--launcher.XXMaxPermSize
256m
-vmargs
-Xms40m
-Xmx512m
-XX:MaxPermSize=256m
[dmadmin@cs-0 scripts]$

What does that mean for the script to deploy DARs? Well, what might be the simplest solution to keep backward compatibility with older versions of Documentum as well would be to use the Java shipped in the Composer Headless, if any, and otherwise use the global JDK referenced in the JAVA_HOME environment variable. The problem is that OpenText keeps changing their packaging and it will probably continue to change in the future, so I believe it’s important to stay as agile and generic as possible. It would be possible to fetch the Java path from the dardeployer.ini file but I don’t know, I have the feeling that it would be safer to just find the file without relying on something put there by the OpenText installers. The future will tell if this was the right call. Anyway, so here would be an updated content of the script to automatically choose the Java and run the command (you can also add an additional check to make sure it is indeed a JDK 8 if you want):

[dmadmin@cs-0 scripts]$ cat deploy-all.sh
#!/bin/bash
docbases="GR_REPO1"
dar_list="D2-DAR.dar"
username="dmadmin"
dar_location="$DM_HOME/install/DARsInternal"
password="xxx"

java=`find $DM_HOME/install/composer/ComposerHeadless -type f -name java | head -1`
if [[ ! -x ${java} ]]; then
  java=$JAVA_HOME/bin/java
fi

old_ifs=${IFS}
for docbase in ${docbases}; do
  IFS=','; for dar in ${dar_list}; do
    dar_name=${dar##*/}

    echo "Deploying ${dar_name} into ${docbase}"
    ts=$(date "+%Y%m%d-%H%M%S")

    ${java} -Ddar="${dar_location}/${dar}" 
        -Dlogpath="${dar_location}/dar-deploy-${dar_name}-${docbase}-${ts}.log" 
        -Ddocbase=${docbase} -Duser=${username} -Ddomain= -Dpassword="${password}" 
        -cp $DM_HOME/install/composer/ComposerHeadless/startup.jar 
        org.eclipse.core.launcher.Main 
        -data $DM_HOME/install/composer/workspace 
        -application org.eclipse.ant.core.antRunner 
        -buildfile $DM_HOME/install/composer/deploy.xml

    if [[ ${?} != 0 ]]; then
      echo "ERROR - There was an error while installing the DAR '${dar_name}' into '${docbase}'"
      exit 1
    fi
  done
done
IFS=${old_ifs}
[dmadmin@cs-0 scripts]$
[dmadmin@cs-0 scripts]$ . ./deploy-all.sh
Deploying D2-DAR.dar into GR_REPO1
Buildfile: $DM_HOME/install/composer/deploy.xml

deploy:
[emc.installer] [INFO]  ******************************************************
[emc.installer] [INFO]  * Headless Composer
[emc.installer] [INFO]  * Version:        20.2.0000.0081
[emc.installer] [INFO]  * Java version:   1.8.0_202 (64bit)
[emc.installer] [INFO]  * Java home:      $DM_HOME/install/composer/ComposerHeadless/java/jdk1.8.0_202_x64/jre
[emc.installer] [INFO]  * Set storage type: false
[emc.installer] [INFO]  *
[emc.installer] [INFO]  * DAR file:       $DM_HOME/install/DARsInternal/D2-DAR.dar
[emc.installer] [INFO]  * Project name:   D2-DAR
[emc.installer] [INFO]  * Built by Composer: 7.1.0000.0186
[emc.installer] [INFO]  *
[emc.installer] [INFO]  * Repository:     GR_REPO1
[emc.installer] [INFO]  * Server version: 20.2.0000.0110  Linux64.Postgres
[emc.installer] [INFO]  * User name:      dmadmin
[emc.installer] [INFO]  ******************************************************
[emc.installer] [INFO]  Install started...  Mon Jun 29 00:18:38 UTC 2020
[emc.installer] [INFO]  Executing pre-install script
[emc.installer] [INFO]  dmbasic.exe output : Connected to the server as dmadmin.
...
...
[emc.installer] [INFO]  dmbasic.exe output : Disconnected from the server.
[emc.installer] [INFO]  Finished executing post-install script Mon Jun 29 00:20:40 UTC 2020
[emc.installer] [INFO]  Project 'D2-DAR' was successfully installed.
BUILD SUCCESSFUL

BUILD SUCCESSFUL
Total time: 2 minutes 15 seconds
[dmadmin@cs-0 scripts]$

With this new update of the script, it should work for all versions of Documentum. As mentioned previously, Documentum 20.2 includes the Oracle JDK 8u202 for the Composer Headless. If I’m not mistaken, this is the last free version of the Oracle JDK licensed under the Oracle BCL (Binary Code License). It means that without a Java OTN (Oracle Technology Network) License, you will NOT be able to patch it; it will need to stay in 8u202.