OraTransplant

Two interesting posts by Steven Chan

I finally managed to read up on all the blogs and stumbled upon two very interesting articles by Steven Chan that are very relevant to us:

• OracleAS 10g Upgrade Paths which describes how Oracle eBusiness Suite handles the upgrade and co-existence of the later AppServer versions. As Steven describes there are a lot of Application Server releases and he is trying to shed some light on them.
• Will the Real JRE Please Stand Up?. This posting describes why you need a specially patches version of Sun 1.5.0_10. Very interesting read and very relevant to us as a technology customer who uses the same tech stack as eBusiness Suite.

Oracle Forms and Sun JVM 1.6

This blog will describe a workaround to get Oracle Forms to work with the newly release version 6 of Sun’s Java SE. When we moved Forms to the web we decided not to use Oracle’s own JInitiator but opted for Sun JPI. I’ve blogged before about the step needed to configure Oracle Forms to use Sun JPI in stead of Oracle JInitiator.

We decided to use dynamic versioning with Sun JPI. This means we specify a minimum required version of the JVM in the webpage, but allow the client to use any newer version installed on the local workstation. The other option is static versioning in which you demand a specific version of the JVM. We didn’t want to use static versioning as the majority of our users are external users over the internet in other organizations. We wanted to make the transition to webforms as smooth as possible and thus allowed them to leverage any existing JVM versions on their workstations.

Oracle officially supports the use of Sun JVM with Oracle Forms. They announced support for Sun JPI 1.4.2 in June 2005 for Forms 10gR1 (9.0.4) and certified JPI 1.5.0 in September 2005 for Forms 10gR2 (10.1.2). My understanding is that Oracle hasn’t begun the certification for J2SE 6 yet.

Since we use dynamic versioning users that do install the new version on their workstation will use J2SE 6 to access our Forms application automatically. So, even without official certification I did some preliminary testing and found two issues. One is related to the use of TLS as HTTPS/SSL protocol combined with Oracle WebCache 10.1.2 which does not work out of the box. I’ll blog about that later. The other issue is that some Forms crashed. When started from the menu they just wouldn’t start and the open window would disappear. Looking at the Java Console an error was displayed:

Exception in thread "AWT-EventQueue-2"
	java.lang.NoClassDefFoundError:
	oracle/bali/share/sort/StringComparator
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
	at java.lang.Class.getDeclaredMethod(Unknown Source)
	at java.awt.Component.isCoalesceEventsOverriden(Unknown Source)
	at java.awt.Component.isCoalesceEventsOverriden(Unknown Source)
	at java.awt.Component.access$100(Unknown Source)
	at java.awt.Component$2.run(Unknown Source)
	at java.awt.Component$2.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.awt.Component.checkCoalescing(Unknown Source)
	at java.awt.Component.(Unknown Source)
	at java.awt.Container.(Unknown Source)
	at oracle.ewt.lwAWT.LWComponent.(Unknown Source)
	at oracle.ewt.lwAWT.LWDataSourceChoice.(Unknown Source)
	at oracle.ewt.lwAWT.LWChoice.(Unknown Source)
	at oracle.ewt.comboBox.ComboBox.(Unknown Source)
	at oracle.ewt.comboBox.ComboBox.(Unknown Source)
	at oracle.forms.ui.VComboBox.(Unknown Source)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Unknown Source)
	at java.lang.Class.newInstance0(Unknown Source)
	at java.lang.Class.newInstance(Unknown Source)
	at oracle.forms.handler.UICommon.instantiate(Unknown Source)
	at oracle.forms.handler.UICommon.onCreate(Unknown Source)
	at oracle.forms.handler.PopListItem.onCreate(Unknown Source)
	at oracle.forms.handler.ComboBoxItem.onCreate(Unknown Source)
	at oracle.forms.engine.Runform.onCreateHandler(Unknown Source)
	at oracle.forms.engine.Runform.processMessage(Unknown Source)
	at oracle.forms.engine.Runform.processSet(Unknown Source)
	at oracle.forms.engine.Runform.onMessageReal(Unknown Source)
	at oracle.forms.engine.Runform.onMessage(Unknown Source)
	at oracle.forms.engine.Runform.processEventEnd(Unknown Source)
	at oracle.ewt.lwAWT.LWComponent.redispatchEvent(Unknown Source)
	at oracle.ewt.lwAWT.LWComponent.processEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
	at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
	at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

It turns out that the Forms applet is trying to use the oracle.bali.share.sort.StringComparator class which cannot be found in the frmall.jar that was used to start Forms. According to the error stack it has something to do with the initialization of a ComboBox. Opening the frmall.jar indeed revealed that the StringComparator class is not included. There are a number of other classes in the oracle.bali.share.sort package: Comparator, LexiComparator and Sort

I also searched the other JAR files in the ORACLE_HOME/forms/java directory but none of them contained the StringComparator class. In fact, the only two JAR files in the entire ORACLE_HOME that contained the class where ORACLE_HOME/oui/jlib/shared.jar from the Universal Installer and ORACLE_HOME/jlib/share.jar

I’ll see if I can get Oracle to look at this problem even without official support for J2SE 6 but I guess they will want to support version 6 eventually. I tried two quick-and-dirty solutions to the problem. One is to include share.jar in the list of JAR files to start Oracle Forms. The other is to slipstream the oracle.bali.share.sort classes from the share.jar in the frmall.jar.

Including the share.jar in the formsweb.cfg

The first solution is to include the share.jar in the distribution. In our current installation of Forms 10.1.2.0.2 the share.jar does not contain any classes that are also included in the frmall.jar. First is to copy the ORACLE_HOME/jlib/share.jar to ORACLE_HOME/forms/java/share.jar. You also have to include the share.jar in the archive parameter of the formsweb.cfg

But the frmall.jar is a signed jar. If you do not sign the share.jar as well you will get a SecurityException:

java.lang.SecurityException:
	class "oracle.bali.share.sort.StringComparator"'s signer
	information does not match signer information of other classes
	in the same package
	at java.lang.ClassLoader.checkCerts(Unknown Source)
	at java.lang.ClassLoader.preDefineClass(Unknown Source)
	at java.lang.ClassLoader.defineClass(Unknown Source)
	at java.security.SecureClassLoader.defineClass(Unknown Source)
	at java.net.URLClassLoader.defineClass(Unknown Source)
	at java.net.URLClassLoader.access$000(Unknown Source)
	at java.net.URLClassLoader$1.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(Unknown Source)
	at sun.applet.AppletClassLoader.findClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at sun.applet.AppletClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClass(Unknown Source)
	at java.lang.ClassLoader.loadClassInternal(Unknown Source)
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
	at java.lang.Class.getDeclaredMethod(Unknown Source)
	at java.awt.Component.isCoalesceEventsOverriden(Unknown Source)
	at java.awt.Component.isCoalesceEventsOverriden(Unknown Source)
	at java.awt.Component.access$100(Unknown Source)
	at java.awt.Component$2.run(Unknown Source)
	at java.awt.Component$2.run(Unknown Source)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.awt.Component.checkCoalescing(Unknown Source)
	at java.awt.Component.(Unknown Source)
	at java.awt.Container.(Unknown Source)
	at oracle.ewt.lwAWT.LWComponent.(Unknown Source)
	at oracle.ewt.lwAWT.LWDataSourceChoice.(Unknown Source)
	at oracle.ewt.lwAWT.LWChoice.(Unknown Source)
	at oracle.ewt.comboBox.ComboBox.(Unknown Source)
	at oracle.ewt.comboBox.ComboBox.(Unknown Source)
	at oracle.forms.ui.VComboBox.(Unknown Source)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Unknown Source)
	at java.lang.Class.newInstance0(Unknown Source)
	at java.lang.Class.newInstance(Unknown Source)
	at oracle.forms.handler.UICommon.instantiate(Unknown Source)
	at oracle.forms.handler.UICommon.onCreate(Unknown Source)
	at oracle.forms.handler.PopListItem.onCreate(Unknown Source)
	at oracle.forms.handler.ComboBoxItem.onCreate(Unknown Source)
	at oracle.forms.engine.Runform.onCreateHandler(Unknown Source)
	at oracle.forms.engine.Runform.processMessage(Unknown Source)
	at oracle.forms.engine.Runform.processSet(Unknown Source)
	at oracle.forms.engine.Runform.onMessageReal(Unknown Source)
	at oracle.forms.engine.Runform.onMessage(Unknown Source)
	at oracle.forms.engine.Runform.processEventEnd(Unknown Source)
	at oracle.ewt.lwAWT.LWComponent.redispatchEvent(Unknown Source)
	at oracle.ewt.lwAWT.LWComponent.processEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
	at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
	at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
	at java.awt.Container.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)

So, you have to sign the share.jar with the same certificate that was used to sign the frmall.jar. Out of the box the frmall.jar is signed by Oracle and we do not have the keystore required to sign the jar file. You will have to sign the frmall.jar with your own certificate and use the same certificate to sign the share.jar file. In September 2005 I already blogged about signing the frmall.jar with your own certificate.

Slipstreaming classes in the frmall.jar

The other solution is to slipstream the classes from the oracle.bali.share.sort package in the frmall.jar. You have to unpack both the share.jar and the frmall.jar. Then copy the classes from the oracle/bali/share/sort directory from the share.jar to the unpacked frmall.jar. Then repack frmall.jar and sign it. You can follow the steps in another blog entry to unpack jar files, repackage and sign them.

Conclusion

Adding the classes to my Forms server does seem to resolve the problem with the crashing Forms. However, I’m sure this is not a supported solution and I don’t really like the concept of just grabbing a number of classes from a JAR file and use them just because their names match. Who knows which version is actually required and why Forms apparantly does not require these classes when using Sun JPI 1.4 or 1.5.

I’ll see if I can get Oracle to look into the problem and will update this blog entry with any progress I make with running Forms with Sun J2SE 6. The coming weeks I will use J2SE 6 with Oracle Forms 10.1.2.0.2 on my machine and will report back here with any issues.

Oracle e-Business Suite will use Sun JPI

Pankaj Chandiramini reports Oracle e-Business Suite 12 will replace Oracle’s own JInitiator with the native Sun Java2 Standard Edition, also known as Sun’s Java Plug-In (JPI).

We’ve been running Sun JPI since summer 2005 and had some minor troubles in the beginning, when Sun JPI wasn’t officially supported by Oracle. Oracle eBS also making the switch to Sun JPI is good news for all of us. This means JPI will get even more attention as a platform for running Forms. Currently, most documentation and MetaLink notes still assume you’re running Oracle JInitiator. eBS making the switch might change this and will make live easier for me

Pankaj also reports eBS 12 will make the switch to the latest platform, which is Application Server 10.1.2 for Forms/Reports and Application Server 10.1.3 for the Java stuff. I bet they would have liked a single platform based on 10.1.3, but Forms is skipping the 10.1.3 platform and will go from 10.1.2 to 11.x. That’s probably why they do this split configuration, since they do want to use the latest J2EE based stuff on 10.1.3.

Forms 10.1.2 supports Sun JPI 1.5

Grant Ronald just released the updated the statement for Client Support of Oracle Forms 10g release 2 (10.1.2). The most noticeable change with the 10g release 1 (9.0.4) version is the added support for Sun Plug-In v1.5 on Windows and the official support of Mozilla Firefox (albeit only with JInitiator and not the Sun Plug-In).

For us this is great news. The majority of our users are external to us and work in hospitals and other medical institutions throughout Europe. When migrating to the web we decided to go for the Sun Plug-In and not the Oracle JInitiator. External sysadmins are a lot more willing to install Sun Plug-In than they are to install the unknown Oracle JInitiator. In fact, most of the time some version of Sun Plug-In is already installed on a workstation.

We also decided to use dynamic versioning of the Sun Plug-In and not dynamic versioning. What this means is that we do not mandate an exact version of the Sun Plug-In, but rather state a minimum version of the Plug-In and also accept any newer version. You can find a couple of blog entries about how we set this up.

Unfortunately you cannot supply both a minimum and maximum version with dynamic versioning of a Java applet. You just get to specify a minimum version. In our case we specified 1.4.2_04 as this is the version that was installed at all our internal machines at the time. When someone tries to start our application and does not have an appropriate version of Sun JPI, we supply the download URL in the page. We still point this to 1.4.2 to encourage our users to install Java 1.4.2 and be using an Oracle certified client.

However, some of the external sysadmins just grab a Java version of the Sun site and that’s mostly 1.5. Also, even if a user installs 1.4.2 the applet will warn the user that a newer version is available and will ask the user to upgrade. In the end this makes a lot of our users use Sun JPI 1.5.

We had some issues with Sun JPI 1.5 and although Oracle was willing enough to log these as bugs as they had to be fixed eventually, there was no way for us to track the bug or keep a TAR open for this since it wasn’t a supported configuration. Now that Oracle has officially announced support for Sun JPI 1.5 in the Forms 10g release 2 product, we can go ahead and push for a solution.

Re-signing Forms JAR file

The default JAR file that comes with Oracle Forms is signed by a certificate issued to “Developer” by “Oracle”. This doesn’t sound very trustworthy to most users. Besides that, the dialog of Sun’s JPI/JRE mentions that the security certificate was issued by a company that is not trusted.

You can choose to re-sign the JAR file yourself and have your own company name in this warning. You can even get Sun JPI to trust the company that signed it.

When you’re going to re-sign the JAR file you can either buy a commercial certificate from any of the well known vendors like Verisign or Thawte. You can also decide to issue your own certificate. This is not as secure, but might do the trick for you. If you issue your own certificate, you’re best of using Oracle Certificate Authority, which is part of Oracle Application Server. That way, you can make all your self-issued certificates use one and the same root certificate. You just have to import this one root certificate in your browser and JVM and all your self-issued certificates will be trusted. Read another blog entry for more information.

Signing the JAR file with your own certificate is documented in an Oracle whitepaper. The section about “Problems With Multiple Signing Identities” explains how to resign the f90all.jar yourself. I just used the JDK that comes with Oracle Developer Suite. Be sure to use RSA as the key algorithm as the default won’t work. Basically the steps using Oracle Certificate Authority are as follows:

rem Create key (and keystore)
%ORACLE_HOME%\jdk\bin\keytool -genkey -keyalg RSA
   -dname "cn=YourName,o=YourCompany,c=NL" -alias signing_cert
   -keypass ******** -keystore c:\keystore -storepass ********
   -validity 2922
rem Create Certification request (get it approved by CA)
%ORACLE_HOME%\jdk\bin\keytool -certreq
   -file c:\signing_cert.req -alias signing_cert
   -keypass ******** -keystore c:\keystore -storepass ********
rem Import the root certificate of your OCA
%ORACLE_HOME%\jdk\bin\keytool -import -alias root_cert
   -file c:\root.cer -keystore c:\keystore -storepass ********
rem Import the approved certificate into the keystore
%ORACLE_HOME%\jdk\bin\keytool -import -alias signing_cert
   -file c:\signing_cert.cert -keypass ********
   -keystore c:\keystore -storepass ********

rem extract Forms 90420 JAR file
md c:\temp\f90all
cd c:\temp\f90all
%ORACLE_HOME%\jdk\bin\jar -xvf
   %ORACLE_HOME%\forms90\java\f90all.jar

rem delete meta information from extracted JAR
rd c:\temp\f90all\META-INF /s/q

rem repackage JAR
cd c:\temp\f90all
%ORACLE_HOME%\jdk\bin\jar -cvf c:\temp\f90all_repackaged.jar *.*

rem Sign the new JAR
%ORACLE_HOME%\jdk\bin\jarsigner -keystore c:\keystore
   -storepass ******** -keypass ********
   c:\temp\f90all_repackaged.jar signing_cert

If you do not want to use Oracle Certificate Authority you can just skip the steps to create a certification request and importing the two certificates from OCA. You can also choose to buy a real signing certificate in which case you do not use OCA to process your certification request, but you use a trusted company like Verisign or Thawte.

Now that you have your self-signed JAR file, just place it in the forms90/java directory on your application server and refer to it in the archive and/or archive_jini parameters of your formsweb.cfg.

Sun JPI will still raise a dialog-box asking the user to allow the Forms applet to run outside of its sandbox. You cannot get rid of this dialog as it is by the design of Java that the user always has to allow an applet to run outside of its sandbox. But now at least it shows your own name and not “Oracle” and “Developer”.

If you’ve not bought a “real” certificate from a commercial party, the dialog will warn the user that the security certificate was issued by a company that is not trusted. You can get rid of this one by importing your own certificate (or root certificate from OCA) in the keystore of your JVM. You can read all about that in a separate blog entry. In the end your warning will look like this:

Importing self-signed certificates in Sun JPI

As you might now from other blog entries, we’re running Oracle Forms using Sun’s JRE/JPI and not JInitiator. We’re using commercial certificates for some of our webservers, but we’re also using some self-signed certificates for our development/test server and for code signing. Up until now all users where presented with a warning about these “invalid” certificates by Sun’s JPI.

I tried before to import our self-issued certificates in Sun’s keystore, but I never managed to get it working. It was allways asking for the keystore password, and I couldn’t find anywhere what the default password for such a keystore would be. Lukelly I found it today on the internet and the default password is "changeit". That’s probably some good advice

I’ve blogged before about importing certificates in JInitiator. You could read there that we are using oracle Certificate Authority to create our own certificates. The advantage to that is that all self-issued certificates are “children” of our self-issued root certificate. This gives me the advantage that I only have to import this root certificate in a browser/JVM and not all certificates that were created of this root certificate.

You could export the certificate from OCA, or you can just get it from Internet Explorer. Just visit a HTTP site that uses the certificate and double-click on the yellow lock in the status bar. Go to the Certification Path tab and double-click the root certificate to open it. No go to the Details tab. If you do not have a self-issued root certificate you can just start of at the Details tab of your initial certificate. Click on Copy to File and save the certificate in base64 encoding.

Now open a command box and change your working directory to the lib\security subdirectory of your Sun JPI. Then execute the keystore command to import your certificate:

C:\>cd "\Program Files\Java\j2re1.4.2_09\lib\security"

C:\Program Files\Java\j2re1.4.2_09\lib\security>..\..\bin\keytool
   -import -file "c:\temp\self.cer" -keystore cacerts
   -storepass changeit -alias myRootCA
Owner: O=Eurotransplant International Foundation, C=NL
Issuer: O=Eurotransplant International Foundation, C=NL
Serial number: 1
Valid from: Mon Feb 21 08:59:26 CET 2005
   until: Thu Feb 19 08:59:26 CET 2015
Certificate fingerprints:
         MD5:  **:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**
         SHA1: **:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**
Trust this certificate? [no]:  yes
Certificate was added to keystore

Now, when you try to start your Oracle Forms application the applet will no longer complain about untrusted certificates for SSL communication. It will still ask the user to accept the Java applet as it is trying to run outside its sandbox. You cannot get rid of this message, as it is by design that Java will ask the user permission for an applet to run outside its sandbox.

The applet as shipped by Oracle is signed by “Developer/Oracle” and uses a self-issued certificate. If you want to get rid of this, you’ll have to re-sign the JAR file yourself with your own certificate. For more information see another blog entry.

Forms 10g certified with Sun JPI

Oracle finally did it! They certified Forms 10g with Sun Java PlugIn. Last week they release patchset 9.0.4.2 for Developer Suite and Application Server. You can read about it in the updated version of the Client Platform Support Statement.

For us, this is great. We’ve got about 300 internal and 400 external users. The external users are in different hospitals and other medical institutions throughout Europe. Getting their sysadmins to install JInitiator can be a challenging task. We’ve found it to be much easier to have them install the well known Sun Java Plugin than the unknown Oracle JInitiator. We already took a risk by deploying based on Sun JPI before it was officially certified.

The only downside to this all is that Oracle only certifies Sun JPI v1.4.2. Certification for version 1.5 is foreseen for Forms 10.1.2 to be released in the second half of 2006.

How to configure Forms to use Sun JPI

I just got a question from a blog visitor how they can get Forms to use Sun JPI and not Oracle JInitiator. I’ll try to explain the exact steps in this post. First of all, I have to warn you that Sun JPI is not (yet) certified. This is also stated in the Oracle Client Platform Support statement. However, they are targeting for the next patchset to support it.

We have a lot of external users in Europe. We found that getting their sysadmins to accept Oracle JInitiator can be a challenging task. Getting the to install the well known Sun JPI is much easier. I do not always agree with them, but that’s just the situation we have to live with.

Here are the changes we made:

• In formsweb.cfg change baseHTML, baseHTMLjinitiator and baseHTMLie to “basejpi.htm”. You could also make a copy of basejpi.htm to create your own custom base file and point to that file.
• The setting of IE=native or IE=JInitiator is no longer relevant. Basically, what this does is determine if the setting for baseHTMLjinitiator (IE=JInitiator) or baseHTMLie (IE=native) should be used. Since we changed both base-parameters to point to the same file, this is no longer relevant.
• The basejpi.htm uses several variables from the formsweb.cfg in the EMBED and OBJECT tags. These are: jpi_download, jpi_classid, jpi_codebase and jpi_mimetype. I’ve played around with these parameters for quite a while. I’ve explained in a previous blog posting about these settings and which values we eventually used.

Settings for dynamic versioning with Sun JPI and Oracle Forms

Our Oracle Forms (10g) application will be used by a lot of remote/external users. Convincing their sysadmins to install Oracle JInitiator can be a tedious task. That’s why we’re aiming to use Sun’s JPI in stead of Oracle JInitiator. Unfortunately this is not supported by Oracle yet, but they’re targeting for the next patch to support Sun JPI.

Anyhow, there are four settings in your formsweb.cfg file that are relevant to the Sun JPI and to determine which version to use and where to download it:
jpi_classid – The ClassID of the Sun JVM to use (Internet Explorer specific)
jpi_codebase – Download location of the CAB file for the Sun JVM (IE specific)
jpi_mimetype – Used primarily for Netscape/Firefox but also passed on to IE
jpi_download_page – Download location of the JRE installer for Netscape/Firefox

I’ve been reading Sun’s Plug-In Developer Guide of both version 1.4.2 and version 1.5.0. The most interesting parts are the sections on Multi-Version support (v1.4.2 and v1.5.0), chapter 3 on using tags (v1.4.2 and v1.5.0) and Appendix 6 on Implementation-Version formats.

You have the option for static or dynamic versioning. Static versioning mandates an exact version of Sun JPI to be installed on the workstation, whereas Dynamic versioning just states a minimum version and every higher version will also do. We will go with dynamic versioning to give as much flexibility to our users as possible.

JPI_CLASSID should be set to clsid:8AD9C840-044E-11D1-B3E9-00805F499D93 for dynamic versioning or to clsid:CAFEEFAC-<major version>-<minor version>-<patch version>-ABCDEFFEDCBA for static versioning. For example, the classID for Sun JPI v1.4.2_04 would be clsid:CAFEEFAC-0014-0002-0004-ABCDEFFEDCBA. We will go with “clsid:8AD9C840-044E-11D1-B3E9-00805F499D93”

With static versioning JPI_CODEBASE should be a URL to the .CAB file to download this exact version. A list of possible URLs is available at Sun. For dynamic versioning the URL consists of two parts, separated by a #-sign. The last part specifies the minimum required Java version. An example is Version=1,4,2,4 for Java v1.4.2_04. The first part of the URL should point to the CAB file to download when the required (or a higher) version is not installed on the workstation. You could point to the CAB file of specific version (e.g. http://java.sun.com/update/1.5.0/jinstall-1_5_0_02-windows-i586.cab for Sun Java v.1.5.0_02). You can also just use the version number of a family to automatically download the latest version of this family (e.g. http://java.sun.com/update/1.5.0/jinstall-1_5-windows-i586.cab will now download v1.5.0_03). In our case, we’re running our application over HTTPS. We needed to change all external URLs in the HTML to also use HTTPS, otherwise Internet Explorer raises a warning about combining secure and non-secure items on the same page. Luckily Sun’s download sites are also available through HTTPS, so we can use https://java.sun.com/update/1.5.0/jinstall-1_5-windows-i586.cab#Version=1,4,2,4 to use at least v1.4.2_04 and if that’s not available the latest version of the v1.5 family will be downloaded and installed.

JPI_MIMETYPE is a mime-type in a format like “application/x-java-applet;<version_type>=<implementation_version>”. For static versioning, <version_type> should be set to “jpi-version”. For dynamic versioning, this should be set to “version”. For static versioning, the <implementation_version> should note the required Java version. For dynamic versioning, this should state the minimum required version. Appendix 6 of the Developer Guide shows the syntax of this <implementation_version>. You can just require a family or a very specific version/patch. Use “version=1.4.2_04” to require at least v1.4.2_04. This makes the entire mime-type “application/x-java-applet;version=1.4.2_04”. However, this did not seem to work with Firefox, so we want to the more generic “application/x-java-applet;version=1.4.2”.

JPI_DOWNLOAD_PAGE is the URL where Netscape/Firefox users can download the JRE. Sun’s examples show this as http://java.sun.com/j2se/1.5.0/download.html. Again, we changed this to use https to prevent warnings in your browser, making it https://java.sun.com/j2se/1.5.0/download.html

Conclusion is that the best settings for us are:

• jpi_classid=clsid:8AD9C840-044E-11D1-B3E9-00805F499D93
• jpi_codebase=https://java.sun.com/update/1.5.0/..
..jinstall-1_5-windows-i586.cab#Version=1,4,2,4
• jpi_mimetype=application/x-java-applet;version=1.4.2
• jpi_download_page=https://java.sun.com/j2se/1.5.0/download.html

Update 30-jun-05: I’ve changed the jpi_codebase to https://java.sun.com/update/1.4.2/..
..jinstall-1_4-windows-i586.cab#Version=1,4,2,4 This still ensures a minimal required JPI version of v1.4.2_04. However, when it’s not installed the latest version of 1.4.2 (currently 1.4.2_08) will be downloaded. We’ve switched back from 1.5 to 1.4.2 since we were having compatibility issues with JPI 1.5. Also, we started out with Forms 9.0.4.1.0 which wasn’t certified with Sun JPI. Since then, Oracle released patch 9.0.4.2.0 which does certify Sun JPI as client. However, it only certifies against v1.4.2. Certification for v1.5.x is foreseen for Forms v10.1.2.

Update 29-oct-2005: Perhaps you should change all references to JPI 1.4.2_04 with 1.4.2_06 for your own installation. Oficially 1.4.2_06 is the minimal version required by Oracle. The reason we went for 1.4.2_04 is that most of our installed base had 1.4.2_04 and we didn’t want to force an upgrade of Sun JPI on those users.

Update 2-may-2006: In the update of 30-jun-05 I mentioned the forthcoming support for Sun JPI v1.5.x in Forms 10.1.2. Last summer, we tested Sun JPI 1.5.x with Forms 9.0.4.2 and ran into some issues. We were in close contact with Oracle Support, Product Management and Development to get our heads around it. In the end we couldn’t really find what the problem was. It resulted in an (unpublished) bug being published and a mention of the issue in the Forms 10.1.2.0.2 release notes. Section 4.1.4.4 of the release notes now mention that Sun JPI 1.5.x might sometimes make your Internet Explorer hang when closing the browser on Windows XP. It looks like this issue is fixed in Sun JPI 1.6.x but that’s not expected to be released for a couple of months. So in the end, we decided to stick to our configuration parameters that try to the latest version of the 1.4.2.x family, although we do accept 1.5.x when this is installed on your workstation. That’s a downside of using dynamic versioning; we can specify a minimum version to use but not a maximum version.