Using multiple JREs

For some applications, you may want to control the version of the Java Runtime Environment (JRE) that the application runs on. DSJ provides a means to control the target JRE on the clientÆs machine.

One scenario might be that an applicationÆs developer has tested the application to ensure that it performs properly on version 1.1.3 of the Sun JDK. The developer wants the application to be run on 1.1.3 and not on any version prior to that. A different developer may have another application for which it doesnÆt matter what version of the JRE is used. For this application, whatever JRE is already present at the client is sufficient.

Identifying JREs

The DSJ client is a Java application; in order for it to run, the client must have a version of the JRE present. The DSJ client has the ability to identify the version of the JRE it is currently executing. A JRE version is identified by a combination of three properties:

Version; for example, "JDK1.1.2Borland"
Vendor; for example, "Sun Microsystems Inc."
Platform; for exampe, "Win32"

An identification string is constructed by concatenating these properties with spaces in-between. For example, the string which represents the JDK supplied with BorlandÆs JBuilder version 1.01 would be: "JDK1.1.2Borland Sun Microsystems Inc. Win32" and the 1.1.4 JRE downloadable from SunÆs Web site would be: "1.1.4 Sun Microsystems Inc. Win32". (Note that this information alone does not identify the Java Language Specification version that the JRE implements.)

As part of the DSJ client/server connection negotiation process, the clientÆs current JRE version plus a list of all other JREs available to the client are communicated to the server along with the name of the desired application. The server can compare the clientÆs current JRE with the JRE preferences that were specified during the applicationÆs installation.

Specifying JREs

The applicationÆs JRE preferences are described by the following entries in the applicationÆs .app file:

If an application has a RequiredJRE specified for it and that JRE is the one that the client is currently running, then no action needs to be taken. If the application requires a specific JRE and that JRE already exists on the client (even though it is not the currently executing one) then the DSJ server will instruct the client to restart itself using the correct JRE.

If the required JRE does not exist on the client at all and the JRE has been loaded onto the server, the server will perform a remote installation of the required JRE and then restart the client. If the required JRE is specified, but does not exist on the client and has not been loaded onto the server, then the application request will fail. If the application has a RequiredJRE, then the values for PreferredJRE and AlternateJRE are ignored.

Specifying a PreferredJRE allows the DSJ administrator to select a JRE, given the JREs that already exist on the client machine. For example, if a DSJ client connects to the server using version 1.1.1 but the client machine also has version 1.1.5, setting a PreferredJRE value of: "1.1.5 Sun Microsystems Inc. Win32" would cause the client to restart using the newer JRE. Another client that does not have version 1.1.5 would not attempt a download of that JRE, because 1.1.5 is a PreferredJRE, not a RequiredJRE.

You may specify a secondary preferred JRE with the AlternateJRE property.

Note: There is currently no way to specify a JRE range, like "any JRE later than 1.1.2".

An applicationÆs JRE preferences may be specified in the Runtime page of the Application dialog box:

If there are no required or preferred JREs, select Any.
If the application requires a specific JRE, select Required and type the identification string for that JRE in the First text field to the right.
If the application has preferred JREs, select Preferred. The First text field is the PreferredJRE, and the Second text field is the AlternateJRE.

Installing JREs

A JRE on a DSJ server is made up of a description file (jreinfo.dsj) and a data file (jre.zip). There is one directory for each JRE loaded onto the server. The DSJ server will use its JREDirectories option in dsj.properties to determine where to look for directories that contain installed JREs.

There are two ways to install a JRE. It can be done manually by creating the appropriate zip and info file or the DSJ server can automatically create it from a existing instance.

To have the DSJ server install the JRE automatically:

While the server is not running, set the serverÆs JREDirectories option in the dsj.properties file to a directory which will contain the serverÆs JREs. For example:
```
    JREDirectories=c:\dsj\jres
```
Use the JREÆs installation utility to install the JRE to a subdirectory under the JREDirectories. For example, install to c:\dsj\jres\newjre. Among other things, this will cause the subdirectories \Bin and \Lib to be created.
Start the DSJ server. The DSJ server will start looking for subdirectories in the directory specified by JREDirectories. In each subdirectory it finds, it looks for a jreinfo.dsj file. If it doesnÆt find one (it wonÆt the first time) it will see if the directory structure indicates that a JRE has been installed by looking for a \Bin and \Lib subdirectory. If those subdiretories are present, the server zips together all the files in the base directory (c:\dsj\jres\newjre) plus the contents of the \Bin and \Lib subdirectories (c:\dsj\jres\newjre\bin, c:\dsj\jres\newjre\lib) and their subdirectories.
The resulting data file is written to the base directory as jre.zip and a corresponding info file (jreinfo.dsj) is created. The jreinfo.dsj file contains the identifying characteristics of the particular JRE. The jreinfo.dsj file that results from installing SunÆs 1.1.4 JRE for Windows contains:
```
    JavaPlatform=Win32
    JavaVersion=1.1.4
    JavaVendor=Sun Microsystems Inc.
    JavaSpecificationVersion=unknown
    JavaSpecificationName=unknown
    JavaSpecificationVendor=Sun Microsystems Inc.
    DSJDestinationDirectory=Sun114
    DSJDatafile=c:\dsj\jres\newjre\jre.zip
```
If any of the lines contain "unknown", it means that the DSJ server was not able to determine that aspect of the JRE. You should edit the file with a text editor to fill in any unknown properties.
At this point the JRE has been sucessfully loaded into the DSJ server. Now that the JRE image and data file have been created, the full JRE installation may be removed from the machine. All DSJ needs is the jreinfo.dsj and jre.zip files. Note that the jreinfo.dsj file has an entry that contains the location of the jre.zip file. You can move the jre.zip file if you want; just change the jreinfo.dsj file accordingly. (The jreinfo.dsj file must remain in a subdirectory of the serverÆs JREDirectories.)
On subsequent invocations of the DSJ server, the existence of the jreinfo.dsj file indicates to the server that this directory and all its subdirectories have been processed. The information in the jreinfo.dsj file describes the JRE to the server. If the server ever has a need to install the JRE to a client it will assume that the jre.zip file contains everything necessary.

For manual installation, if a suitable JRE has been installed on another DSJ server, its jreinfo.dsj and jre.zip files may be moved or shared with this DSJ server.

Alternatively, you may create a .zip file using a zip utility so that it contains the contents of the \Bin and \Lib subdirectories as found in any of the JREs. The jreinfo.dsj file may be created by any text editor. Then they just need to be put in a subdirectory underneath the directory specified by the DSJ serverÆs JREDirectories option.

Note: As downloaded from SunÆs site, the JRE for Windows comes as an InstallShield self-extracting installation EXE. The Solaris JRE is a .zip file which is already exactly as desired for DSJ.

Next Previous Up