Since starting at my new company I’ve been very aware of how limiting Oracle is becoming with Forms 10g, in that most applications use the bundled Jinitiator which is getting old with very few of the new Java Beans playing well. Recently a new project has come up that requires a lot image manipulation and mantaining the image quality without Oracle Forms standard compression techniques. Due to the way the current application has been built in forms (non-database tables mostly) we investigated alternative method for the image manipulation. One of the ways we came up with was using the Image handling in Java via the Image Quality Java Bean (http://forms NULL.pjc NULL.bean NULL.over-blog NULL.com/ext/http://sheikyerbouti NULL.developpez NULL.com/forms-pjc-bean/menu/). This then lead us down the path of investigating how our Forms application is tied down so tightly to the OS (MUST be XP) the browser (MUST be IE) and version (MUST be 6 or 7), failing any of these checks the user was likely to have problems running our Application and more and more time was spent on supporting this.
So, we decided to look into getting the Forms Application running under a new version of Java and under Java Web Start. The biggest point of reference was the excellently Jan Carling’s blog (http://groundside NULL.com/blog/JanCarlin NULL.php?title=forms_and_java_web_start&more=1&c=1&tb=1&pb=1). Different from his set up we have a bespoke Single Sign-On security set up that requires us to pass a hash-key into the application which, using Web Start, required us to dynamically generate the JNLP.
As my knowledge was in PHP we decided to create the files in PHP where possible.
One of the issues we wanted to avoid on roll-out was ‘what Java versions do the users have installed annd does it meet the requirements?’. As a note, the minimum we required was the Java JRE 6 Update 12. Web Start came into being at Update 10 but both update 10 and 11 didn’t play well with our Forms Applicaiton and there were alot of graphical problems, most notably the whole menu system was messed up…why?…we couldn’t figure it out, hence the minimum being Update 12.
1. startApp.php
In order to check the minimum set up we created a PHP start file called startApp.php that used the Java Deployment Kit, which would also run the dynamic JNLP file. Below is the code for the file;
<?php header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in the past header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Cache-Control: no-store, no-cahce, must-revalidate"); header("Pragma: no-cache"); $code=$_GET['code']; // get url parameter ?> <script src="http://localhost/forms/java/deployJava.js"></script> <head> <script type="text/javascript"£ language="javascript"> function loadApp() { var url="http://localhost/forms/java/forms_dynamic.php?code=<?=$code?>"; if (deployJava.isWebStartInstalled('1.6.0_12')) { deployJava.launch(url); closeWindow(); } else { var targetJRE= '1.6.0_16'; var jres = deployJava.getJREs(); var patt1=new RegExp(targetJRE); if (patt1.test(jres)==false) { deployJava.installJRE(targetJRE); deployJava.refresh(); if (deployJava.isWebStartInstalled('1.6.0_12')) { deployJava.launch(url); closeWindow(); } else { alert('App requires JRE 1.60_12'); } } } } function closeWindow() { /* close the browser window if App successfully loaded */ window.opener='Self'; window.open('',' parent',''); window.close(); } </script> </head> <body onLoad="javascript:loadApp();"> </body> </html>
We stored this file on the Application Server in %ORACLE_HOME%\tools\web\html, which resolves to /forms/html in the url. As you can see we first check Java is installed, and if so then it meets the minimum requirement. If these conditions are met the we start the JNLP file forms_dynamic.php through the deployJava.lauch() command.
2. forms_dynamic.php
startApp.php file called the forms_dynamic.php which was the dynamic JNLP. Below is the code;
<?php header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); // Date in past header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Cache-Control: no-store, no-cahce, must-revalidate"); header("Pragma: no-cache"); header("Content-Type: application/x-java-jnlp-file"); $code=$_GET['code']; // get url parameter ?> <jnlp spec="1.0+" codebase="http://localhost/forms/java"> <information> <title>Forms Applications</title> <vendor>Company Name</vendor> <description>Forms Application - Java Web Start</description> <homepage href="http://localhost" /> </information> <security> <all-permissions /> </security> <resources> <j2se version="1.6+" /> <jar href="frmall.jar" size="" main="true" /> <extension name="other_jars" href="other_jars.jnlp"/> </resources> <applet-desc main-class="oracle.forms.engine.Main" name="Forms" width="995" height="600"> <param name="separateFrame" value="false" /> <param name="lookAndFeel" value="oracle" /> <param name="splashScreen" value="false" /> <param name="background" value="/forms/html/background.gif" /> <param name="colorScheme" value="titanium" /> <param name="serverURL" value="/forms/lservlet? ifcfs=http://localhost/forms/frmserlvet?config=jpi" /> <param name="serverApp" value="default" /> <param name="logo" value="false" /> <param name="serverArgs" value="module=startup.fmx userid=@db sso_userid= debug=no buffer_records=no debug_messages=no array=no query_only=no quiet=yes render=no host= port= record= tracegroup= log= usesdi=yes param_jnlp=TRUE CODE=<?=$code?>" /> </applet-desc> </jnlp>
By having the line
header("Content-Type: application/x-java-jnlp-file");
we don’t need to add a mime type to the application server to recognise the JNLP, this is all done in the startApp.php file by the deploy.launch() command.
We stored this file on the Application Server in %ORACLE_HOME%\forms\java, which resolves to /forms/java in the url and holds the JAR files. As you can see only the JAR frmall.jar is referenced directly in the php file. This is because JNLP files require all JARs to be signed with the same certificate, something we couldn’t do as we’d created a few ourselves, and for the application to start it requires frmall.jar which is signed by Oracle. So, the line
<extension name="other_jars" href="other_jars.jnlp"/>
points to another JNLP file, for all the other JARs. The file other_jars.jnlp code is below;
<?xml version="1.0" encoding="UTF-8"?> <jnlp spec="1.0+" codebase="htpp://localhost/forms/java/" href="other_jars.jnlp"> <information> <title>Forms Application</title> <vendor>Company Name</vendor> <offline-allowed/> </information> <offline-allowed/> <resources> <jar href="webutil.jar"/> <jar href="jacob.jar"/> </resources> <component-desc/> </jnlp>
As you can see it just a pointer JNLP for all the JARs besides frmall.jar to be used by the application. ANY other JARs that are to be used should be placed in the %ORACLE_HOME%/forms/java directory and referenced in this JNLP file.
This is a pretty standard php file for deployJava.js. The only different bit is picking up the _GET['code'] url parameter. Again, this is the parameter passed from the single sign-on function that is required to be passed into the application, through the dynamic JNLP. All making sense?
This starts Java Web Start, as if the Forms Web Application is run using the /forms/frmservlet?config=jpi setting (check Forms Web App through Sun Java )
—
So to recap, first call the start<applicationname>.php with the url parameter code=1234, which through the deployJava.lauch() function calls the dynamic JNLP file forms_dynamic.php which kicks off Java Web Start, running the application using the config=jpi standard web app.
…and there you have your Forms 10g app running as it’s own Java Web Start application.