Deploying Plex Java Applications

From The CA Plex Wiki

Jump to: navigation, search


This page is part of the Everyday Tasks Using Plex Java topic. To read an introduction and see other related pages visit the introduction page. Associated pages:


Contents

Introduction

This section describes the process for deploying Plex generated Java Client programs and the Server programs, which support them.

Server

There is one major decision affecting how you will deploy your server programs.

1) What platform and language do you want to use on the server?

If you want complete platform independence, you will generate your server programs in Java. This will allow you to run your server programs on any computer platform, which supports Java�which is all the popular ones. You will pay a price in performance for this decision with most computer platforms, because Java is not a native language and does not hard compile on most platforms.

If server-computer-platform independence is not an issue I suggest you use a language native to the server. Remember, you are using a CASE tool to create your programs�and aiming a CASE tool at a new platform using a different generator is not the amount of work that rewriting your entire application would be. One person emailed me asking how they could speed up their Java server programs on an AS/400. I told them to change the generated server language to RPG, when deploying on an AS/400 server.

Plex generated Java client programs call server programs generated using RPG, WinC, etc. just fine.

The steps to setup a server differ with each platform, and you should refer to the documentation for the platform you pick. If you are using one of the Java server platforms, you will need to configure a Java dispatcher. There is a simple example of how to do this with your own PC in the section of this document named, �Using Your PC as a Java Server”. Setting up other Java servers is similar�but varies with each type of server.

If you do not generate server code in Java, you do not need to start the Java dispatcher�unless watching dispatcher jobs that do nothing is of interest to you…

Client

There are two major decisions that affect what steps you will follow to deploy Java client programs.

1) Are you going to ship people an application or deliver applets directly from a web server? 2) Are you going to package your class files in Java Archives (jars) or deliver them as individual objects?

Application or Applet or Webstart

Delivering Java client programs as applications is similar to delivering C++ client programs. You bundle up everything and send it to people on a CD, in a Zip file, using InstallShield, etc. This has the advantage of giving you complete control over every object you send to the end user, and makes sure all the versions match�leaving nothing to chance. This has the disadvantage of making you responsible for keeping everything up to date, and shipping new versions of objects whenever there are changes. If you pick the approach of delivering applications, think of your target �client”�as being the PC on the desktop of your end users.

Delivering Java programs as applets means you deliver everything from a web server. This takes advantage of the power of the current generation of web browsers, which assemble the applets from the one set of current objects you keep on your web server. This is the typical approach for delivering Java programs. This has the disadvantage of delivering everything you need to send to your end user over the potentially low-speed communication lines of the Internet or an Intranet. If you pick the approach of delivering applets, think of your target �client”�as being your web server. Your end users use a web browser from the PC on their desktops to get to your web server �client”.

The main difference between application and applet is how the program is executed and deployed, not how it is generated and compiled.

Java Webstart

In addition, to Applications and Applets the Java platform provides a third deployment method for Java clients. Java Webstart enables clients to be deployed via a web browser but executed on the client as a standalone application. Thus, Webstart can be considered a "combination" of the applet and application approaches.

This page has some examples of Webstart applications:

http://java.sun.com/products/javawebstart/demos.html

Jars or Individual Objects

Java Archives are like zip files used to package Java programs. Delivering client programs using jar files has the advantage that your users only need to download each jar once for each version, and they have the entire contents on their PC. Delivering with jar files has the disadvantage that your end users must wait for the entire jar(s) to load, before they can start running anything.

Delivering individual class objects (.class files) has the advantage that your end users only need to load the class objects they will use in a given situation. Delivering individual class objects has the disadvantages that the objects can�t be compressed as they can be with jar files.

If you are deploying applications, the choice between distributing jars or individual class objects should be decided based on which method is the most convenient for you to distribute and update your application. I suggest you should always distribute the Sun and Plex class objects in the jars they come in, like rt.jar, i18n,jar, ObRun.jar and OBPTJAVA.JAR. I suggest you will find distributing your client application(s) in jars makes it easier to keep track of versions and avoid mixing incompatible versions of objects.

If you are deploying applets only from a web site, I suggest you will need to use jars only. I tried unzipping the ObRun.jar and OBPTJAVA.JAR objects and delivering these as individual class objects. I found that when running one simple display panel and one simple grid panel, that 104 of the ObRun .class objects downloaded with a total uncompressed size of 485kb. It would have downloaded more, but the JRE Plug-in failed with an �OutOfMemory”�error message that displayed on the Plug-in Console. The total compressed size of the ObRun.jar is 760kb, and using it avoids the �OutOfMemory”�error message. I suggest you put the Java applets you write into jars too.

Another approach is to distribute some jar objects directly to your end users and others via a web site. This approach will only make sense when you are dealing with an internal distribution and not the general public using the Internet. If you have a situation where you can control an internal distribution, I suggest that you deliver the big jar objects, which don�t change very often, directly to your end users and deliver the smaller jar objects, which change often, via a web site.

At release level 4.5 of Plex, the jar objects are:

1) ObRun.jar 760kb.

2) OBPTJAVA.JAR 900kb.

These two objects total 1,660kb or over 1.5mb. Allot of data for your users to download, before they can run your programs.

Backwards Compatibility of Obrun.jar

Note that unlike C++, the Java runtime for later releases is backwards compatible with earlier releases back to 4.5. This means that you can deploy, say, the 5.5 release of Obrun.jar with an application that was generated at 4.5 or 5.0. This means you can take advantage of fixes and improvements in the latest version of the runtime without having to do a full upgrade to that release. Check the Plex help text for details on how to configure this. CA periodically publishes updated versions of Obrun.jar on the support web site.

Another big plus point compared to Plex C++ is that when you do upgrade to a new release you generally don't need to re-gen or re-build existing Java functions.

What Does Not Work

The reason most people write Java programs is to deploy them from a web site. This section assumes that is what you will be doing. If you choose to deliver applets from your web site, they will run inside a web browser like Microsoft Internet Explorer (MSIE) or Netscape Navigator (NN).

The APPLET Tag

Both of the last few versions MSIE and NN have stopped supporting the APPLET tag in such a way that you can use it with Plex Java and many other Java programs. I tried the following HTML to start a Plex Java program with Internet Explorer versions 5.0 and 5.5. (This HTML is a hand-edited version of what you get if you generate the non-Plug in HTML):

<HTML>
  <HEAD>
    <TITLE>
      CustomerSignon
    </TITLE>
  </HEAD>
  <BODY>
    <APPLET
      CODE="ObRun.ObPanel.ObLaunch.class"
      CODEBASE="http://MyServer.com/MyAppRoot/HTML/Java/"
      ARCHIVE="ObRun.jar,OBPTJAVA.Jar,MyApplication.jar"
      WIDTH="355"
      HEIGHT="300"
      NAME="ObLaunch"
      ALIGN="baseline">
      <PARAM NAME="Function" VALUE="CLIENT.CustomerSignon">
      <PARAM NAME="Properties" VALUE="http://MyServer.com/MyAppRoot/HTML/Java/">
          The APPLET tag failed while trying to load a version 1.2.2 Java applet named CustomerSignon.
          This is problem with a program that you can't fix.
    </APPLET>
  </BODY>
</HTML>

The lines that read…

The APPLET tag failed while trying to load a version 1.2.2 Java applet named CustomerSignon. This is problem with a program that you can't fix.

only display if the APPLET tag fails to execute.

NOTE: I have removed all optional spaces from the HTML. Some browser versions have trouble with the spaces, especially spaces separating the names of multiple jar files. NOTE for IF/CW: Don�t use optional spaces in HTML.

The result of testing this HTML with Internet Explorer versions 5.0 and 5.5 is the display of the following four messages on the status line:

Opening Java archive ObRun.jar
Opening Java archive OBPTJAVA.jar
Opening Java archive CustomerAccess.jar
load: ObRun.ObPanel.ObLaunch can't be instantiated


I searched the CA support site for this, and found a) I no longer exist and, b) neither do 2E or Plex. Undaunted, and self-assured of my own existence, I looked up the load: ObRun.ObPanel.ObLaunch can't be instantiated error message on Microsofts web site. I found what I wanted after several days of searching, using the keywords, Tell me what the load: ObRun.ObPanel.ObLaunch can't be instantiated’ error message means or I will give a deposition to the US Department of Justice, Anti-Trust Division.” (The commas are required.) The answer reads that you should use the HTML OBJECT tag instead of the APPLET tag, because the APPLET tag has been Deprecated” and because Janet Reno is no longer the US Attorney General. Phooey, on both counts.

By the way, somebody needs to buy Microsoft and Sun some dictionaries. They both use the word, Deprecated to mean discontinued, replaced, tossed in the trash, whatever… If you look up Deprecated in Websters New Twentieth Century Dictionary, Unabridged, Second Edition dictionary it has three definitions:

1. to pray against; to pray deliverance from; as to deprecate the return of war. [Archaic.] 2. to plead or argue earnestly against; to urge reasons against; to feel and express strong disapproval of. 3. to implore mercy of. [Obs.]

Since definition “1.” is Archaic and definition “3.” is Obsolete, I guess someone is expressing strong disapproval of the APPLET tag. Of course the Twentieth Century version of Websters is not Y2K compliant so maybe that's the problem.

The Microsoft support page I found the Deprecated business on has a link to the HTML 4.0 standards (along with a picture of former US Attorney General, Janet Reno with some of her teeth blacked out). I read the HTML 4.0 standards document and found definitions and examples of the OBJECT tag.

The OBJECT Tag (without the Sun Java Plug In)

Using the HTML 4.0 standards document examples as a model, I changed my HTML to the following:

<HTML>
  <HEAD>
    <TITLE>
      CustomerSignon
    </TITLE>
  </HEAD>
  <BODY>
    <OBJECT
      CODETYPE="application/java"
      CLASSID="ObRun.ObPanel.ObLaunch.class"
      CODEBASE="http://MyServer.com/MyAppRoot/HTML/Java/"
      NAME="ObLaunch"
      WIDTH="355"
      HEIGHT="300"
      ALIGN="baseline">
      <PARAM NAME="Function" VALUE="CLIENT.CustomerSignon">
      <PARAM NAME="Properties" VALUE="http://MyServer.com/MyAppRoot/HTML/Java/">
          The OBJECT tag failed while trying to load a version 1.2.2 Java applet named CustomerSignon.
          This is problem with a program that you can't fix.
    </OBJECT>
  </BODY>
</HTML>

The lines that read…

The OBJECT tag failed while trying to load a version 1.2.2 Java applet named CustomerSignon. This is problem with a program that you can't fix.

�only display if the OBJECT tag fails to execute.

The result of this test is that Internet Explorer displays:

The OBJECT tag failed while trying to load a version 1.2.2 Java applet named CustomerSignon. This is problem with a program that you can't fix.

Odd, the Microsoft documents say the OBJECT tag works? I had the Internet Explorer Java console open at the time, and it displayed no messages. Also, there were no error messages on the status line of Internet Explorer. Double Phooey!

I tried the OBJECT tag with my copy of the HelloWorld.class, which I created when I took the Sun Java tutorial, and got the same results.

I tried the APPLET tag with my HelloWorld.class, and this worked.

I don�t know why Microsoft says Internet Explorers supports the OBJECT tag. I could not get it to work without the Sun Java Plug-in.


What Does Work - The Sun Java Plug-In

You may be wondering why I went to all the trouble of trying to get the APPLET tag and the OBJECT tag to work without the Sun Java Plug-in (JRE), since the Plex documentation says to use the Plug-in. The reason is simple. The Sun Java Plug-in is a 5mb to 7.5mb download, which I wanted to avoid. There are several versions of the Plug-in you can choose. Currently these are:

Version 1.2.2_007 Standard Edition jre-1_2_2_007-win.exe 5,251kb

Version 1.2.2_007 International Edition jre-1_2_2_007-win-i.exe 7,321kb

Version 1.3.0_02 Standard Edition j2re-1_3_0_02-win.exe 5,026kb

Version 1.3.0_02 International Edition j2re-1_3_0_02-win-i.exe 7,576kb


If you use the Plug-in, your end users have to wait while their web browser downloads one of these. This creates a very bad, �out of the box”�experience for your users, because the download means your end users have to wait through 5mb to 7.5mb of downloads�before they ever see one of your programs. Depending on how you need to configure the Plug-in, these downloads can occur without any messages or other indication that they are happening�other than the web browser not responding. I read an IBM study on user perceptions of response times a few years ago. IBM found users perceived:

  • Response time User perception
  • Under ½ second Instantaneous
  • Under 1 second Good
  • 1 to 2 seconds Slow
  • 2 to 5 seconds Bad
  • Over 5 seconds Computer is broken.

A download of 5mb to 7.5mb is going to take over 5 seconds, unless your users have direct, high-speed LAN connections to your web server. The user will most likely think the computer is broken, and either a) close the web browser, or b) hit Refresh�and start the download over.

Ugh!


If you have been reading the Plex documentation or have looked through some Plex example HTML code, you may be wondering why I have not mentioned the �jinstall-1_2_2-win.cab”�Plug-in object. Plex version 4.5 generates Plug-in HTML that has the following line inside the scope of the OBJECT tag:

CODEBASE="http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab#Version=1,2,2,0">

This is a 41kb object that contains the JavaBeanBridge [to ActiveX] and just enough code to start the download of the Java version 1.2.2 runtime engine or JRE Plug-in. There is one definite advantage to using this object. Your user only has to wait for a 41kb download, before this panel displays:

JavaHowTo007.jpg

If the user clicks on �Yes”, they get this panel�which lets them pick between the 5,251kb �U.S. English”�version (the �Standard Edition”) or the 7,321kb �International [Edition]”�version:

JavaHowTo008.jpg

Once they click on Install, the user gets a progress screen that looks like this:

JavaHowTo009.jpg

Unfortunately, there are problems with this approach. Your users have to be able to get to the Sun web site at http://java.sun.com. If you are deploying to an Intranet, locked inside a firewall, this may not be possible. Also, your user must pick the International Edition or the ASCII to EBDIC translation won�t work. (Big problem if you are using an IBM server.) My guess is most users in the US will pick the default �U.S. English”�Edition, thinking they are making the correct choice.

An example of working HTML for this approach is:

<code>

<HTML>
  <HEAD>
    <TITLE>
      CustomerSignon
    </TITLE>
  </HEAD>
  <BODY>
    <OBJECT
      CLASSID="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
      WIDTH="355"
      HEIGHT="300"
      NAME="ObLaunch"
      ALIGN="baseline"
      CODEBASE="http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab#Version=1,2,2,0">
      <PARAM NAME="CODE" VALUE="ObRun.ObPanel.ObLaunch.class">
      <PARAM NAME="CODEBASE" VALUE="http://MyServer.com/MyAppRoot/HTML/Java/">
      <PARAM NAME="NAME" VALUE="ObLaunch">
      <PARAM NAME="TYPE" VALUE="application/x-java-applet;version=1.2.2">
      <PARAM NAME="Function" VALUE="CLIENT.CustomerSignon">
      <PARAM NAME="Properties" VALUE="http://MyServer.com/MyAppRoot/HTML/Java/">
          The OBJECT tag failed while trying to load a version 1.2.2 Java applet named CustomerSignon.
          This is problem with a program that you can't fix.
    </OBJECT>
  </BODY>
</HTML>

</code><pre>

I will explain all of this HTML code in a few pages.

Another big problem with this approach is your users may want to pick the US English version, because they are in the US and believe they speak English. They have to download the International version or they will get a panel that looks like the one in the Mysterious Error Messages…�section of this document. 
If you are locked inside a firewall, and can�t get to the Sun web site�there is another approach. The approach is to deliver the Plug-in directly. You do this by loading the Sun JRE Plug-in you want on your Intranet web server and changing the CODEBASE parameter in the HTML to one of the following four choices, depending on which version and variation of the JRE Plug-in you pick:

CODEBASE="http://MyServer.com/MyAppRoot/HTML/Java/jre-1_2_2_007-win.exe">	JRE 1.2.2_007 Standard

CODEBASE="http://MyServer.com/MyAppRoot/HTML/Java/jre-1_2_2_007-win-i.exe">	JRE 1.2.2_007 International

CODEBASE="http://MyServer.com/MyAppRoot/HTML/Java/j2re-1_3_0_02-win.exe">	JRE 1.3.0_02 Standard

CODEBASE="http://MyServer.com/MyAppRoot/HTML/Java/j2re-1_3_0_02-win-i.exe">	JRE 1.3.0_02 International

The problem with this approach is that your users don�t get any indication that the 5mb to 7.5mb object is downloading until the download has finished.

An example of working HTML for this approach is:

<pre><code>

<HTML>
  <HEAD>
    <TITLE>
      CustomerSignon
    </TITLE>
  </HEAD>
  <BODY>
    <OBJECT
      CLASSID="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
      WIDTH="355"
      HEIGHT="300"
      NAME="ObLaunch"
      ALIGN="baseline"
      CODEBASE="http://MyServer.com/MyAppRoot/HTML/Java/jre-1_2_2_007-win-i.exe">
      <PARAM NAME="CODE" VALUE="ObRun.ObPanel.ObLaunch.class">
      <PARAM NAME="CODEBASE" VALUE="http://MyServer.com/MyAppRoot/HTML/Java/">
      <PARAM NAME="NAME" VALUE="ObLaunch">
      <PARAM NAME="TYPE" VALUE="application/x-java-applet;version=1.2.2">
      <PARAM NAME="Function" VALUE="CLIENT.CustomerSignon">
      <PARAM NAME="Properties" VALUE="http://MyServer.com/MyAppRoot/HTML/Java/">
          The OBJECT tag failed while trying to load a version 1.2.2 Java applet named CustomerSignon.
          This is problem with a program that you can't fix.
    </OBJECT>
  </BODY>
</HTML>

</code>

An alternative I have considered is prying apart the jinstall-1_2_2-win.cab object and changing it to point to an instance of one of the above four JRE objects loaded on a web server inside the firewall. This will destroy the VeriSign signatures in the jinstall-1_2_2-win.cab object, but, since we are talking about an Intranet distribution, signatures should not be as important as they would be in an Internet environment. If you need a VeriSign signature, you will have to get one and �sign”�the new object. There are two objects inside this cab object. One of them is the jinstall_1_2_2.inf object, which has a line that reads:

run=%EXTRACT_DIR%\jinstall.exe http://java.sun.com/products/plugin/1.2.2/jinstall_1_2_2.ini

I suspect this line could be changed to point at a different URL. You would have to figure out what is in the jinstall_1_2_2.ini object and modify that as well. I have not tried this.

If you browsed around the Sun web site during the first releases of Java 1.3, you may have noticed there used to be a Plug-in object called plugin1_1_3-win.exe. For a time, Sun was distributing the version 1.3 Plug-in this way. With version 1.2.2 of Java, Sun only distributed the Plug-in as part of the total runtime engine or JRE, so you have to load the jre-1_2_2_007-win.exe or similar object. Sun seems to have changed back to the approach of only delivering the Plug-in as part of the total runtime engine package, because the plugin1_1_3-win.exe object is no longer available and you have to load the j2re-1_3_0_02-win.exe object or similar.

The primary differences between the various Plug-in objects are the version levels of the runtime engine and which jars are delivered.

For version 1.2.2_007, the jars for the �Standard Edition”�are:

plugprov.jar 13kb

rt.jar 9,001kb

jaws.jar 498kb

For version 1.2.2_007, the jars for the �International Edition”�are the �Standard Edition”�jars plus:

i18n.jar 4,515kb

iiimp.jar 82kb

For version 1.3.0_02, the jars for the �Standard Edition”�are:

sunrsasign.jar 85kb

rt.jar 11,394kb

jaws.jar 812kb

For version 1.3.0_02, the jars for the �International Edition”�are the �Standard Edition”�jars plus:

i18n.jar 4,788kb

The rt.jar and i18n.jar from the Plug-ins are not the same jar objects you get when you load the same versions of the Java JDKs on your PC. These jars are smaller, because the developer .class and .gif objects have been removed.

A key difference between the �Standard Edition”�and the �International Edition”�is the i18n.jar object. It is only in the �International Edition”�versions of the Plug-in. If you are not supporting multiple concurrent National Languages (French, English, Dutch, Finnish, Norwegian, Klingon, Romulan, etc.), you only need two objects from the i18n.jar object. These are:

CharToByteCp037.class 3.4kb

ByteToCharCp037.class .8kb


These are the objects used to do ASCII-EDCDIC conversions for Code Page 37. You only need these if, a) you have an AS/400 (or some other IBM EBCDIC platform) as a Web or back-end server, and, b) you are using Code Page 37 (US English). These two objects total 4.2kb in size�allot less that the 2.1mb to 2.5mb difference in the size of the Plug-in variations. There are a couple of ways to get around using the �International Edition”�and reducing the size of the Plug-in needed by 2.1mb to 2.5mb. One approach is to load the ASCII-EDCDIC conversion objects on your web server. The full path names where Sun Java looks for these are:

�MyAppRoot\HTML\Java\sun\io\CharToByteCp037.class

�MyAppRoot\HTML\Java\sun\io\ByteToCharCp037.class

I tried this, and could not get it to work. I think the problem is that the Standard Edition of the Plug-in does not look for objects in the i18n.jar. If anyone figures out how to make this work, PLEASE let me know�so we call all save 2mb of downloads for our end users.

Another approach is to used Code Page 1252 (Latin characters) instead of 37 (US English). The same objects for Code Page 1252 are in the rt.jar object, and not in the i18n.jar object. Only the Code Page 1252 objects are in the rt.jar object. All other Code Page objects are in the i18n.jar object.

I have not tested this approach, because I can�t dictate the Code Page on the server. If anyone figures out how to make this work, PLEASE let me know�so we call all save 2mb of downloads for our end users.

Another point to consider when using the Sun Java Plug-in is that the rt.jar is delivered as part of the Plug-in. Obviously there is no need to load this on your web server, since your users will get it as part of the Plug-in.

In controlled Intranet environments, you might want to ship the Sun Java Plug-in, the ObRun.Jar, the OBPTJAVA.JAR and any other large objects that don�t change often, directly to your end users. This approach will only make sense when you are dealing with an internal distribution and not the general public using the Internet. If you have a situation where you can control an internal distribution, I suggest that you deliver the big objects, which don�t change very often, directly to your end users and deliver the smaller objects, which change often, via a web site.


Details of the OBJECT Tag

The OBJECT tag is similar, but not identical, to the APPLET tag. The following is a description of its parameters, and how to fill them out for Plex Java, the Sun Java Plug-in and Microsoft Internet Explorer version 4.01 and above.

This is the example of the OBJECT tag from an earlier page in this document.

<code>
<OBJECT
  CLASSID="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
  WIDTH="355"
  HEIGHT="300"
  NAME="ObLaunch"
  ALIGN="baseline"
  CODEBASE="http://MyServer.com/MyAppRoot/HTML/Java/jre-1_2_2_007-win-i.exe">
  <PARAM NAME="ARCHIVE" VALUE="ObRun.jar,OBPTJAVA.JAR">
  <PARAM NAME="CODE" VALUE="ObRun.ObPanel.ObLaunch.class">
  <PARAM NAME="CODEBASE" VALUE="http://MyServer.com/MyAppRoot/HTML/Java/">
  <PARAM NAME="NAME" VALUE="ObLaunch">
  <PARAM NAME="TYPE" VALUE="application/x-java-applet;version=1.2.2">
  <PARAM NAME="Function" VALUE="CLIENT.CustomerSignon">
  <PARAM NAME="Properties" VALUE="http://MyServer.com/MyAppRoot/HTML/Java/">
          The OBJECT tag failed while trying to load a version 1.2.2 Java applet named CustomerSignon.
          This is problem with a program that you can't fix.
</OBJECT>
</code>

The OBJECT tag must start with <OBJECT> and end with </OBJECT>.

The first few parameters are directly within the scope of the <OBJECT> tag. You must put these first and place a ">" after the last one to indicate you are finished with the direct parameters.


The CLASSID parameter must be set to "clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" for Sun Java. This is the Windows registry key for all Sun Java runtimes and does not change from version to version or between the �Standard Edition”�and the �International Edition”.


The WIDTH and HEIGHT parameters tell the web browser what size gray box to put around your panel. These should match your panel size if you are framing inside the web browser. If you are not framing inside a web browser, omit the WIDTH and HEIGHT parameters to avoid displaying a useless gray rectangle on the web browser.


The NAME parameter is used to refer to an instance of an applet. It can be set to anything you want. If you display the same applet twice on the same browser page, you need to give the instances different NAME parameter values if you want to be able to refer to the instances.

You can omit this parameter.


The ALIGN parameter tells the web browser how to align a framed panel on the page. You can set this to left, right, top, texttop, middle, absmiddle, baseline, bottom, or bsbottom.


The CODEBASE parameter is used to find the Sun Java Plug-in you are using. The various settings for these are described a few pages back in this document.


This is the end of the parameters directly within the scope of the “�OBJECT”�tag. You must place a “>” after the last one of the above that you have used.


Next come the “�PARAM”�parameters. These come before the “</OBJECT>”�tag, but have their own scope. These start with “�PARAM”�and end with “>”.�The PARAM parameters are used by the JRE to figure out what program to call. These can also be used by every Java applet called after that. The first four PARAM parameters in the example are used by the JRE. Plex Java uses the last two.

1) <PARAM NAME="ARCHIVE" VALUE="ObRun.jar,OBPTJAVA.JAR">

This is the ARCHIVE parameter, which is equivalent to the APPLET ARCHIVE parameter. If you are deploying jars, you list them here. It is essential that you do not put spaces between the names of multiple jars, because some browser versions will stop looking for more jars when they encounter a space.


2) <PARAM NAME="CODE" VALUE="ObRun.ObPanel.ObLaunch.class">

This is the CODE parameter, which is equivalent to the APPLET CODE parameter. You must set this to a VALUE of ObRun.ObPanel.ObLaunch.class to tell the JRE you want to run a Plex Java program.


3) <PARAM NAME="CODEBASE" VALUE="http://MyServer.com/MyAppRoot/HTML/Java/">

This is the CODEBASE parameter. This tells the JRE the path where your class objects and/or jar files are located. This path must be subordinate to the location of the HTML that calls the Java program. For example, if your HTML is in folder http://MyServer.com/MyAppRoot/HTML/, your CODEBASE parameter must point to that folder or a sub-folder of that folder. You can omit the CODEBASE parameter. If you do, your class objects and/or jar files must be in the same folder as the HTML, which calls them. In the Plex examples you will see in the help text and the generated objects, the CODEBASE parameter is always set to a value of “./”.�This means use the same folder as the HTML�which means the same thing as omitting the CODEBASE parameter. Some descriptions of this parameter will tell you to use relative addressing. For example, if your HTML is located in folder…

http://MyServer.com/MyAppRoot/HTML/

�and your class objects and/or jar files are located in folder…

http://MyServer.com/MyAppRoot/HTML/Java/

�you could specify a relative CODEBASE parameter of �Java/”. I advise against this approach, because it does not always work. I suggest you always use a full path like �http://MyServer.com/MyAppRoot/HTML/Java/”.

The folder you put your applets into MUST be a sub-folder of the folder where the initiating HTML is found. For example, if your HTML is in folder http://MyServer.com/MyAppRoot/HTML, your applets must be that folder or a sub-folder, like http://MyServer.com/MyAppRoot/HTML/Java/.

If you get this parameter wrong, you will get messages saying class objects can�t be found.


4) <PARAM NAME="NAME" VALUE="ObLaunch">

This is the NAME parameter and works just like the NAME parameter within the direct scope of the OBJECT tag. This NAME parameter is also used to refer to an instance of an applet. It can be set to anything you want. If you display the same applet twice on the same browser page, you need to give the instances different NAME parameter values if you want to be able to refer to the instances. I don�t know why the Plex examples all use the same NAME parameter value of ObLaunch for both the NAME parameter within the direct scope of the OBJECT tag and the NAME parameter within the scope of the <PARAM NAME="NAME" parameter. The NAME parameter within the direct scope of the OBJECT tag is referring to the JRE. The NAME parameter within the scope of the <PARAM NAME="NAME" parameter is referring to the ObRun.ObPanel.ObLaunch.class. These are clearly not the same applets. Since the scope of these two parameters is different, you could not relate these objects. I think it would be clearer if the NAME parameter within the direct scope of the OBJECT tag was given the value �JRE”�and the NAME parameter within the scope of the <PARAM NAME="NAME" parameter kept the value �ObLaunch”.

You can omit this parameter.

5) <PARAM NAME="TYPE" VALUE="application/x-java-applet;version=1.2.2">

This is the TYPE parameter and should be set to match the version of the JRE you are using. You can omit the “�version=1.2.2”�portion of the parameter. If you leave in the “�version=1.2.2”�portion of the parameter, you must update this whenever you change to a new version of the JRE Plug-in.


6) <PARAM NAME="Function" VALUE="CLIENT.CustomerSignon">

This is the Function parameter, and is the direct equivalent of the same parameter of the APPLET tag. The value of this parameter tells Plex Java which applet is the first program to run. In my example the applet is CustomerSignon, which was built as part of the CLIENT group. My example applet object�s full name is CustomerSignon.class.


7) <PARAM NAME="Properties" VALUE="http://MyServer.com/MyAppRoot/HTML/Java/">

This is the Properties parameter and is the direct equivalent of the same parameter of the APPLET tag. The value of this parameter tells Plex Java where to find the ob450client.properties object. If you get the value of this parameter this wrong, you will get null pointer error messages. Stop! Go find the world�s laziest programmer, whose forehead you have been using for yellow sticky notes and get back the one that reads �If you get a Null Pointer Message, check the location and name of your Client Properties file.”�Add a bit to the end of the note that reads, �Especially on the Web Server.”�Since the glue on the yellow sticky is probably wearing out, use a pushpin to stick it back to the idiot�s forehead. If they still don�t move, have them declared legally dead and have their body carted off (after you collect all your notes of course). Now you will have another PC to use. You�re going to need it to test your applets.


The final lines in the HTML before the </OBJECT> tag read:

         The OBJECT tag failed while trying to load a version 1.2.2 Java applet named CustomerSignon.
         This is problem with a program that you can't fix.

This will display on the web browser if there are any mistakes in your HTML or if you use a Netscape browser. Netscape does not support the OBJECT tag. Netscape uses the EMBED tag. More on that subject next.


Details of the EMBED Tag

The EMBED tag is the Netscape equivalent of the OBJECT tag. It too is similar, but not identical, to the APPLET tag. The following is a description of its parameters, and how to fill them out for Plex Java, the Sun Java Plug-in and Netscape Navigator version 4.07 and above. (I picked version 4.07, because the versions before that do not support multiple jar files, extraneous spaces or not. Single jar applet support was introduced with Netscape Navigator version 4.04.):

This is the example of the EMBED tag, and is the equivalent of the OBJECT tag from the previous example.

<code>
<EMBED
  TYPE="application/x-java-applet;version=1.2.2"
  java_ARCHIVE="ObRun.jar,OBPTJAVA.JAR"
  java_CODE="ObRun.ObPanel.ObLaunch.class"
  java_CODEBASE="http://MyServer.com/MyAppRoot/HTML/Java/"
  NAME="ObLaunch"
  WIDTH="355"
  HEIGHT="300"
  ALIGN="baseline"
  Function="CLIENT.CustomerSignon"
  Properties="http://MyServer.com/MyAppRoot/HTML/Java/"
  pluginspage="http://java.sun.com/products/plugin/1.2/plugin-install.html">
</EMBED>
</code>

The EMBED tag is identical to the OBJECT tag with a few minor parameter name and some other differences.

Unlike the OBJECT tag, all of the parameters of the EMBED tag are directly within the scope of the tag, and you place a “>” after the last parameter. There are no “�PARAM”�parameters with the EMBED tag.

The ARCHIVE, CODE and CODEBASE parameters are prefixed with �java_”, but are otherwise identical.

The one major difference between the EMBED tag and the OBJECT tag is the way Netscape handles the Sun Java Plug-in. Netscape Navigator�s security does not allow the Sun Java Plug-in to be installed on the fly. You must download and save the Plug-in, install it from where you saved it, and stop and start Netscape. This is why the EMBED tag has a pluginspage parameter pointing to an HTML page. The pluginspage parameter in the example is the Sun URL to start this download. The example shown above assumes your users have Internet access. If your users are locked inside a firewall on some Intranet, you will have to create an equivalent to the plugin-install.html object, which points to a place on your web server to start the download. The Sun documentation tells you to copy the one from the above URL and change it.

This is the HTML code I found for doing this with the Netscape browsers. Since I don�t have one of these, I have no idea if it works:

<code>
<html>
  <head>
    <title>
      Install Java Plug-In 1.1.1 for Netscape Navigator
    </title>
  </head>
  <body bgcolor="white">
    <h1>
      Install Java Plug-In 1.1.1
    </h1>
    Click
      <a
        href="file://S103D64G/apptest/plugin-111-win32.exe">
        here
      </a>
    to download the Java Plug-In installer program.
    <br>
    <br>
    Follow these steps to download and install the Java Plug-In:
    <br>
    <ol>
      <li> Download file plugin-111-win32.exe to a temporary directory on your PC.
      <li>Exit your browser.
      <li>Run plugin-111-win32.exe in the temporary directory.
      <li>Restart the applet in your browser.
    </ol>
  </body>
</html>
</code>

This HTML example is pointing to version 1.1.1 of the Sun Java Plug-in, which is obviously not up to date.

Using the OBJECT and EMBED Tags on the Same HTML Page

If you have looked at the Plex documentation or any Plex generated HTML examples, you have already seen this combination of the OBJECT and EMBED HTML tags. The idea behind this HTML is that Internet Explorer and Netscape Navigator will both use the parts they want and ignore the parts they don�t understand. I have changed the indentation to make this point a little clearer:

</code>
<HTML>
  <HEAD>
    <TITLE>
      CustomerSignon
    </TITLE>
  </HEAD>
  <BODY>
    <OBJECT
      CLASSID="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93"
      WIDTH="355"
      HEIGHT="300"
      NAME="ObLaunch"
      ALIGN="baseline"
      CODEBASE="http://java.sun.com/products/plugin/1.2.2/jinstall-1_2_2-win.cab#Version=1,2,2,0">
      <PARAM NAME="ARCHIVE" VALUE="ObRun.jar,OBPTJAVA.JAR">
      <PARAM NAME="CODE" VALUE="ObRun.ObPanel.ObLaunch.class">
      <PARAM NAME="CODEBASE" VALUE="http://MyServer.com/MyAppRoot/HTML/Java/">
      <PARAM NAME="ARCHIVE" VALUE="ObRun.jar,OBPTJAVA.Jar">
      <PARAM NAME="NAME" VALUE="ObLaunch">
      <PARAM NAME="TYPE" VALUE="application/x-java-applet;version=1.2.2">
      <PARAM NAME="Function" VALUE="CLIENT.CustomerSignon">
      <PARAM NAME="Properties" VALUE="http://MyServer.com/MyAppRoot/HTML/Java/">
        <COMMENT>
          <EMBED type="application/x-java-applet;version=1.2.2"
            java_CODE="ObRun.ObPanel.ObLaunch.class"
            java_CODEBASE="http://MyServer.com/MyAppRoot/HTML/Java/"
            Java_ARCHIVE="ObRun.jar,OBPTJAVA.Jar"
            NAME="ObLaunch"
            WIDTH="355"
            HEIGHT="300"
            ALIGN="baseline"
            Function="CLIENT.CustomerSignon"
            Properties="http://MyServer.com/MyAppRoot/HTML/Java/"
            pluginspage="http://java.sun.com/products/plugin/1.2/plugin-install.html">
        <NOEMBED>
        </COMMENT>
        </NOEMBED>
          </EMBED>
    </OBJECT>
  </BODY>
</HTML>
</code>

I had to leave out the lines…

         The OBJECT tag failed while trying to load a version 1.2.2 Java applet named CustomerSignon.
         This is problem with a program that you can't fix.

…, because Netscape Navigator would display them every time.


Modifications to ob450client.properties

For web server applet delivery, you must modify the ob450client.properties file to specify the URL containing your panel resource files, graphic files, and any jar or class objects to be downloaded on demand. Referring back to the section of this document that deals with the ob450client.properties file, I have reproduced the three lines that deal with setting this to use a web server to deliver applets. The line number references are the same as in the section of this document that deals with the ob450client.properties file. The lines involved are 19, 20 and 78:

  1. LK –�The location of the Panel Resources file. For example, MyCleverJavaProgram.panelresource
  2. LK –�This example line 19 shows setup for a web server. The closing “/” is essential.
19 Environment.Default.Resources=http://MyServer.com/MyAppRoot/HTML/Java/
  1. LK –�The location of any GIFs you are using in your application. Same notes as previous line.
  2. LK –�This example line 20 shows setup for a web server. The closing “/” is essential.
20 Environment.Default.ImagePath=http://MyServer.com/MyAppRoot/HTML/Java/Images/
  1. LK –�Filling out line 78 is required for download on demand, which would only be used when
  2. LK –�serving Applets from a web server. The line points to your jar or class objects.
  3. LK –�The first line 78 is how this line should look when you are not using download on demand.
78 Environment.Default.RemoteLoadLocations=
  1. LK –�The second line 78 is filled out to use download on demand. The closing “/” is essential.
78 Environment.Default.RemoteLoadLocations=http://MyServer.com/MyAppRoot/HTML/Java/

There are other lines that control applet behavior. Refer back to the section describing the ob450client.properties file for further details.

Personal tools