I've gotten some questions from customers wanting to know if it's possible to use newer Java JREs with Documaker, so I thought I'd address this in a blog post. First, it's important to note that Oracle Documaker Enterprise Edition (ODEE) has additional software infrastructure requirements such as WebLogic 11g, and these components have specific Java JDK version requirements of their own. These requirements are wholly separate from ODEE. ODEE's requirements are outlined in the Documaker System Requirements guide for each version of Documaker, and the Java-specific requirements are succinctly stated as 32-bit JRE, Java 6 for 12.0-12.2 and Java 7 for 12.3-12.5. I'm suspect that 12.6 will ship with Java 8. ODEE includes the appropriate JRE version with it's installer packages, and it's completely stand-alone, meaning that ODEE does not rely on having a JRE available on the system to use at runtime other than the one it provides. This means that it is possible to replace the JRE that ships with Documaker without affecting other components (e.g. WebLogic or other applications). This blog post will detail how to do that for a Linux system. It's possible to do this for Windows as well, using similar procedures.
It's also very important to note that running Documaker with a non-shipping JRE may not be supported by Oracle, and any particular JRE may not have even been tested. So, keep in mind that doing this may void your warranty - but the process is completely reversible.
First, I'm starting with an Oracle Enterprise Linux 6u3 environment which already has ODEE 12.4 installed. It is possible to use yum to install alternate versions of software, however I haven't found a reliable way to get the 32-bit JRE through this method, so we'll download the JRE directly from Java.com as a GZipped tar. Make sure you download the plain 32-bit "tar.gz" file and not the RPM or 64-bit version ("x64"). Download the file and then copy it to your Documaker server, then unzip/untar it. This will create a directory containing the JRE wherever you run this command.
# tar -xvzf jre-8u121-linux-i586.tar.gz
Before proceeding, make sure you have shutdown any ODEE processes using [ODEE_HOME]/documaker/docfactory/bin/docfactory.sh stop. Also stop any running Docupresentment processes by running [ODEE_HOME]/documaker/docupresentment/docserver.sh stop. Now, let's move the existing JRE into a backup directory and have a look. Notice anything interesting?
# mv jre backup-jre
# ls -ltr backup-jre
-rwxrwxr--. 1 oracle oinstall 5746 Feb 28 2013 java
-rwxrwxr--. 1 oracle oinstall 5746 Feb 28 2013 idswatchdog.exe
-rwxrwxr--. 1 oracle oinstall 5746 Feb 28 2013 idsrouter.exe
-rwxrwxr--. 1 oracle oinstall 5746 Feb 28 2013 idsinstance.exe
-rwxrwxr--. 1 oracle oinstall 5746 Feb 28 2013 docfactory_supervisor
-rwxrwxr--. 1 oracle oinstall 5746 Feb 28 2013 docfactory_scheduler
-rwxrwxr--. 1 oracle oinstall 5746 Feb 28 2013 docfactory_receiver
-rwxrwxr--. 1 oracle oinstall 5746 Feb 28 2013 docfactory_pubnotifier
-rwxrwxr--. 1 oracle oinstall 5746 Feb 28 2013 docfactory_publisher
-rwxrwxr--. 1 oracle oinstall 5746 Feb 28 2013 docfactory_identifier
-rwxrwxr--. 1 oracle oinstall 5746 Feb 28 2013 docfactory_historian
-rwxrwxr--. 1 oracle oinstall 5746 Feb 28 2013 docfactory_batcher
-rwxrwxr--. 1 oracle oinstall 5746 Feb 28 2013 docfactory_archiver
If you said, "Hey, all those files are the same size as the java binary," you're right! Since each ODEE worker is a separate JVM, if you started up ODEE and did a process list, you would see a bunch of java processes and you would have to dig a bit to see which process corresponds to each worker. By copying the java binary and renaming it to each worker, your process list will show each worker by its name (e.g. "docfactory_archiver") instead of "java". This means that we cannot simply rip-and-replace the JRE; we'll have to do a little extra work as well.
# mv jre1.8.0_121 jre
# cd jre/bin
Now that we have our own copy of the JRE, we need to copy the java binary a few times to make our JVM process names reflect the workers inside them. Note: yes, it's strange to have Linux binaries with ".exe" extensions, but there may be some scripts that look for specific process names, so we're doing to leave them just the way they are.
# cp java idswatchdog.exe
# cp java idsrouter.exe
# cp java idsinstance.exe
# cp java docfactory_supervisor
# cp java docfactory_scheduler
# cp java docfactory_receiver
# cp java docfactory_pubnotifier
# cp java docfactory_publisher
# cp java docfactory_identifier
# cp java docfactory_historian
# cp java docfactory_batcher
# cp java docfactory_archiver
At this point, the work is done. Now we simply need to test it. Start up the Document Factory using [ODEE_HOME]/documaker/docfactory/bin/docfactory.sh start. If you see any errors, time to dig a little further - one possible error is that perhaps you forgot to copy the java binary with the proper name, in which case you'd see an error like this:
2017-01-25 19:33:23.827 UTC-ERROR-[Supervisor-Scheduler-1-oracle.documaker.processmonitor.process.monitors.InstanceMonitor]-[Instance.java:1568]
-oracle.documaker.processmonitor.process.instance.Instance.reset: Unexpected exception:
java.io.IOException: Cannot run program "docfactory_scheduler" (in directory "[ODEE_HOME]/odee_1/documaker/docfactory/temp/scheduler"):
error=2, No such file or directory
This error tells us that the file "docfactory_scheduler" does not exist, and so we need to double check that the file [ODEE_HOME]/documaker/jre/bin/docfactory_scheduler exists.
The next step is to start up Docupresentment by running [ODEE_HOME]/documaker/docupresentment/docserver.sh start. The process should start up without any problems, and now you simply need to regression test your implementation to make sure everything functions as you expect. My advice in regression testing is to concentrate on areas outside of Documaker itself (meaning, don't focus regression testing on forms, rather, focus on integration points that utilize Docupresentment. If you use EWPS web services, or DSI interfaces, server-side web pages, or direct queue integration, or any combination thereof, I recommend focusing regression testing there. Good luck!