Initial situation:
COAGO is a Forms 11g product (11.1.2.1.0) by Grass GmbH.
On the client side COAGO is a forms applet running with (status quo) Java7 (32-bit) and OCXe (32-Bit) using the java bridge ComfyJ 2.5 (by TeamDev) embedded.
COAGO starts (Forms applet) via Java-Webstart (and the proper .jnlp script). All COAGO jars even frmall.jar, frmwebutil.jar, jacob.jar etc. are signed with a certificate of VeriSign.
COAGO is exclusively used inside a LAN. (never using the internet)
Our target is, that COAGO runs always and exclusively with java versions/patchlevel approved by Grass GmbH
(For example using JRE 1.7.0_45). It should optionally run with settings that are just valid for the approved java version (deployment.config/deployment.properties) independent which java version is installed additionally. (e.g. JRE 1.7.0_51, JDK 1.8.0_20)
To call our application we use a private JRE SE without an expiration date.
•We installed a jre 7u45 auto-update-off version once using the parameter –STATIC in the command line. We copied the jre directory created thereby (C:\Programme\Java) and deliver it as a copy with our client installation. We copy it to C:\Grass\JRE\ on the client computer.
•Temporary environment variables are defined in a local .ini file. For example we set JAVA_HOME= C:\Grass\JRE. When the user starts the application they are delivered to java webstart previously. Then we start with javaws.exe jnlpurl
•The two files deployment.properties and deployment.config (attached) exist in C:\Grass\JRE\lib. The Oracle client support recommended this process to us to be sure that our java version is used even if a newer version is installed.
Up to know it was possible to install multiple java versions beside our copied directory. The settings in the deployment.properties worked fine. Since jre SE version 7u71 and 8 the deployment.properties file in the user profile is recreated during the installation or usage. Our procedure does not work anymore if these versions are installed on the client. Now, the application starts with the newer jre SE. The reason are new security patches that block deployment applications using older jre versions.
Problem:
To force COAGO to use the JRE version approved by Grass GmbH (no matter which JRE versions are installed) we did the following:
a) copied the approved JRE directory during our client software installation to a specific directory. (status quo JRE 1.7.0_45 in C:\GRASS\JRE)
b) configured the files deployment.config and deployment.properties (in C:\GRASS\JRE\Lib) to validate our JRE for COAGO.
c) called webstart out of the path C:\GRASS\JRE\Bin.
With java 7 Oracle startet to tighten security rules. Every new Java-Patchlevel (1.7.0_xx) had new restrictions. Since Java 1.7.0_71 the local deployment.properties in the user profile is not supplemented but rebuild no matter if webstart is called out of C:\GRASS\JRE\Bin.
We've got a workaround to specify the approved java versions in the .jnlp file from the Oracle JRE Support.
e.g.
<java version="1.7.0_45" href="href="http://java.sun.com/products/autodl/j2se"" />
<java version="1.7.0_51" href="href="http://java.sun.com/products/autodl/j2se"" />
....
But they simultaneously mentioned that this security hole could be closed in coming java versions. It means we cannot use the method to run COAGO from C:\Grass\JRE in the long run.
conclusion:
We are strongly looking for a permanent method to practice COAGO inside LAN envirionments only with jre versions and patchlevels approved by Grass GmbH. The delivered JRE version should be called from C:\Grass\JRE and optionally configured with settings valid just for the delivered java (deployment.config/deployment.properties) no matter which installed java versions the client machine has or will have. The method should be easy transferable to other customers.
We prefer the method (or a method that has similar functions) configuring the files deployment.config and deployment.properties (in C:\GRASS\JRE\Lib) because we also use these settings:
- deployment.security.revocation.check=NO_CHECK
- deployment.proxy.type=0
question:
Is there another method to run a Forms application with the mentioned properties?
Any advice or hint would be appreciated.