
	Corporate Info \| News \| Solutions \| Products \| Partners \| Services \| Events \| Download \| How To Buy
	e-docs \| Site Map \| Search \| Contact \| Glossary \| WebLogic Server Documentation

Publishing with WebLogic ZAC

Introduction
Trying out the ZAC demos
How ZAC works
Setting up WebLogic for publishing with ZAC
Using the Publish Wizard
Debugging and testing a published application

Introduction

WebLogic ZAC, the Zero Administration Client utility, lets you publish and republish applications, applets, and libraries with ZAC, so that they are transparently and automatically updated to the latest version on the end user client machine. With ZAC, you no longer need to manually distribute applications, applets, or libraries to your clients; you can depend on ZAC's automatic services to do so.

ZAC is extremely efficient. When a ZAC application is republished, only the minimal amount of data is sent over the network to each client, to bring the applications on your clients up-to-date. In a typical scenario where little or nothing has changed, the overhead for checking for new files at startup is not noticeable to a user.

ZAC is highly configurable, so that you can design how your application should be published, installed, and updated. You can check for updates to the application and to its dependent libraries each time the application starts or stops; on a scheduled basis, or you can disable the check for new ZAC updates altogether. Although this would disable ZAC's most powerful feature, it may be desirable for packages that you intend to distribute once only as a static version.

ZAC uses a protocol called the HTTP Distribution and Replication Protocol (DRP), a specification submitted to the W3C in August 1997 for the efficient replication of data over HTTP.

This document includes instructions on how to use the ZAC Publish Wizard to publish applications on a WebLogic Server for distribution to your users.

Trying out the ZAC demos

When you install on Windows with the install shield (.exe) version, WebLogic comes out-of-the-box with two ZAC packages, ZSimple and ZUpdate, that you can try out immediately to see how WebLogic ZAC works. (This pre-installed demo is not available if you install from the .zip file.)

Start WebLogic. (You will need to know the system password to publish.)
Start the ZAC Publish Wizard. Win32 users can use the shortcut for ZAC Publisher available in the WebLogic directory in the Start menu.
Non-Windows users can start the Publish Wizard from the command line (after setting your CLASSPATH) with this command:
```
 $ java weblogic.PublishWizard
```
From the Publish Wizard window, double-click the ZSimple or ZUpdate selection. You can walk through all the steps to see a demonstration of how to publish a package, or you can just press the Finish button to skip to the review phase.
Press the "Done" button.
To publish the application, select it in the list and select Publish... from the Package menu. Select the appropriate Host and press the Publish button. If you are only connected to one host, this will be selected automatically for you. A "Publishing..." dialog will display the status of the publish operation and, if successful, the package will appear in the lower-left window of the Publish Wizard, under the selected WebLogic Server host. You may need to expand the "+" symbol to see the published package.
You can test the published package by selecting the package under a WebLogic Server host in the published window (lower-left), then select Test run from the Server menu.

You can open the package again after the test run starts, change a few parameters, and republish the application to see how the client responds.

The rest of this document describes how to create and publish a package, and how to create a bootstrap executable -- which is the standard way to install and run an application from a ZAC package.

How ZAC works

Any Java application, applet, or library can be published as a ZAC package. You do not need to add anything special to the Java source code to publish your program with ZAC. (However, ZAC does include a Java API that you can use in writing your application to add interactive control over when ZAC updates should occur or whether the application should respond immediately to ZAC updates. Developing with the ZAC API is discussed in the Developer Guide, Using WebLogic ZAC.)

ZAC works very simply from your user's perspective.

You publish an application to a WebLogic Server with the ZAC Publish Wizard.
Your user downloads a small native-OS installer, and simply double-clicks to install and start.
The installer creates your application and installs all necessary libraries to support it on the user's machine, as well as a small bootstrap that monitors for new published versions of your application and carries out updates.

How you publish a ZAC package on the server

The ZAC Publish Wizard makes publishing your application easy. You use the ZAC Publish Wizard to:

Create new ZAC packages
Publish ZAC packages on a WebLogic Server
Import ZAC packages from other WebLogic Servers
Update published ZAC packages on a WebLogic Server

The ZAC Publish Wizard guides you through the process of creating and publishing a package with ZAC on a WebLogic Server. During the publish process, you set up the parameters necessary to run your application or ZAC package on the client machine, such as identifying:

Which directories contain the files that comprise your application
Other ZAC packages that your application depends upon
Which Java runtime environment must be present on the client machine
Other necessary information to allow your application to work correctly

An application is published to a WebLogic Server and is made available to your users via HTTP. You can republish the package each time you change your application or any of the libraries on which it depends.

How ZAC installs a published application on the user's machine

When you complete the publishing phase, your application is published on the WebLogic Server. The ZAC Publish Wizard generates a small installation program in native format for each machine type supported by ZAC. Your users download and run this program to install the published application or package. We shall refer to this installation program as the 'installer', in the rest of this document. The installer is a very small executable, and so is quick to download.

To make the published application available to users, just attach the installer to an email or embed an FTP link to it in an HTML page. The user downloads and runs the installer. Since the installation program is a native executable, a user doesn't need to pre-install a Java Runtime Environment (either a JRE or some Java development environment like the JDK).

The installer performs some or all of the following tasks, depending on how you have configured it from the ZAC Publish Wizard:

(Optional) Checks that a specific JRE that will be needed by the published application is pre-installed on the client machine; the ZAC installer can automatically install a JRE that you provide (as another ZAC package) if necessary.
(Optional) Queries the user for HTTP proxy information to connect to the publishing WebLogic Server.
(Always) Downloads and installs the ZAC application.
(Optional) Downloads and installs any other ZAC packages that the published application is dependent upon.
(Always) Installs a bootstrapper executable that is used to start a published application, to monitor the publishing WebLogic Server for new versions, and to download new versions when appropriate.
(Optional) Creates a desktop icon or Start menu item that links to the bootstrapper.
(Optional) Launches the ZAC application.

After the initial installation, the installer may be deleted from the client's machine.

How a published application runs on the user's machine

The installer installs your user application, as well as a native bootstrap file. Once the application is installed, your user will use the native-OS bootstrap to invoke the application. Part of the ZAC Publish Wizard process involves creating the bootstrap program.

Each time the client runs the bootstrapper, it first checks for new versions of the published application on the WebLogic Server. If a new version of your application -- or any other ZAC packages that the ZAC application depends upon -- has been published, the bootstrapper automatically updates the ZAC packages on the client machine with the new versions. The bootstrapper then starts the published application.

Setting up WebLogic for publishing with ZAC

You will need to add and adjust some properties in the weblogic.properties file.

To enable ZAC, find and uncomment or add the property:
```
  weblogic.zac.enable=true
```
Optionally, set an ACL for each published package to limit access. If unset, the write permission defaults to system, and the read permission defaults to everyone.
```
  weblogic.allow.read.weblogic.zac.myApp=userlist
  weblogic.allow.write.weblogic.zac.myApp=userlist
```
Set a publish root for locating published packages. If the publish root is set to a relative path, the directory will be located in the WebLogic home directory (parallel to the myserver\ directory). If unset, this property defaults to the exports\ directory in WebLogic home (for example, c:\weblogic\exports).
```
  weblogic.zac.publishRoot=c:/weblogic/publish
```
Start the WebLogic Server as usual. The WebLogic Server must be running when you can actually publish your ZAC packages, though it need not be running when you are creating the ZAC packages.

Using the Publish Wizard

Starting the Publish Wizard
Creating a ZAC package
Publishing a ZAC package
Using the command line Publish Utility
Connecting the Publish Wizard to other servers
Updating a published ZAC package
Importing a published ZAC package from another server
Creating an installer/bootstrap application
Removing a published ZAC package
Packaging a JRE: Before you begin; Installing a JRE as a package; Specifying a published JRE package for an application

Starting the Publish Wizard

If you wish to publish to a WebLogic Server, that server must be running, and you will need to know a user and password that has permission to publish. For more details, see Publishing a ZAC package. However, you can create and inspect existing ZAC packages without any Servers running.

To start the ZAC Publish Wizard, Win32 users can use the shortcut for ZAC Publisher available in the WebLogic directory in the Start menu. Non-Windows users can start the Publish Wizard from the command line (after setting your CLASSPATH) with this command:

 $ java weblogic.PublishWizard

The ZAC Publish Wizard splash screen will appear while ZAC starts up, then the main dialog for the Publish Wizard will appear:

The ZAC Publish Wizard main window

Creating a ZAC package

You use the ZAC Publish Wizard to create new ZAC packages, import existing packages from other servers, or update previously published packages. A ZAC package may be an application, applet, or library.

The Publish Wizard will guide you through the process of creating a new package or republishing an existing. You can also use ZAC's "test run" option, which allows you to try running your ZAC application to check that it will run as configured.

From the Package menu, select New to create a new package, or Open to view or edit an existing package. Alternatively, you can double-click on an existing package. This will open the Package panel.
On the Package panel, select a package type. You may publish an applet, a Java application, or a class library as a ZAC package. Typically, you publish libraries as a component that other published applications depend upon.

Publishing a new library package

Name the package. This will not be a public display name; it will be used for filename purposes, so make it short and easy to identify. Note: You may not use spaces in the package name.

Naming the package

Supply a title for the package and a short prose description of it. Both will be used for display purposes.

Supplying a title and description

Set the version number.

Setting the version number

Browse to the directory that contains the files for the ZAC package. Everything in the directory you choose, plus everything in all its subdirectories, will be published.
You can exclude files from the published package by adding to the list of file types to be ignored. This allows you to locate files that may be used to generate the package in the same directory, without publishing them. In general, you will always want to ignore index.xml and index.osd files, which are specific to each client. A list of suggested files to exclude is supplied; you can add to or delete from this list for your published package.

Choosing the package's top-level directory

Choosing the top-level directory of the package

Find a GIF image to use as a thumbnail for the package. The image should be 32x32 pixels with a transparent background for best results.

Supplying a thumbnail image

If you are publishing an applet, you will be asked to enter the applet's main class, the CODEBASE, and a list of applet parameters that would customarily be listed in PARAM tags. If the applet is online, you can enter a URL that ZAC will use to find the applet and complete the list of parameters automatically. To identify the applet, supply:

The main classname
If you enter a URL for an online location of the applet (along with the document base), ZAC will find the applet and supply its parameter list automatically.
The document base
This is the URL of the webserver that is hosting the applet. Supplying the document base and the name of the class is enough information for ZAC to find an online running version of the applet and load the parameter list automatically.
The CODEBASE attribute
This is a URL where the applet may retrieve additional class files as required. It is a common practice to set this to http://yourserver:port/classes where yourserver is your WebLogic Server and you have registered the ClasspathServlet against the virtual name classes. For more details see the Administrators Guide on Registering the WebLogic servlets.
The applet parameters
Applet parameters are a list of name=value pairs that supply initialization and runtime variables to the applet, analogous to those supplied between the <APPLET> tags in an HTML file.

Specifying applet parameters

Enter the path to the appropriate class for the published package. If you are publishing an application, you will be asked to enter the full path to the Java class that contains the main() method that starts the application. You may also enter any initialization arguments, required by the main() method, in the Parameters text area.

Locating the class to start the application

Specify the CLASSPATH for your package (Required). If all of the necessary classes are contained in the published package itself, you can simply specify a dot "." for the current directory. The CLASSPATH is always relative to the top-level directory for the application. If you are publishing an application, the class that contains the main() method to run your application must be in the CLASSPATH of the package.
When publishing any type of package, CLASSPATH entries are always relative to the top of the local directory being published. For example, when publishing the local directory c:\myapps -- which contains the following --
```
  c:\myapps\classes\foo\Main.class
  c:\myapps\bundle1.jar
  c:\myapps\lib\bundle2.jar
```
where the class foo.Main is contained in the package foo -- you would set the CLASSPATH for the package as:
```
  classes;bundle1.jar;lib\bundle2.jar
```

Specifying the package CLASSPATH

Here, you may specify Java system properties that your application requires. List one name=value pair per line.

Specifying Java system properties

Next, you may set up dependencies for your package upon other packages. ZAC will ensure those packages are installed and up-to-date on the client machine also. You must make ZAC packages of shared libraries or other applications that your package depends upon, and specify the dependencies using package names.
Using dependencies with ZAC allows several different applications to share common code on the client machine. When common code is updated, it is consequently updated for all dependent ZAC applications.
For example, if you were developing 3 applications that depend upon the WebLogic and the Swing classes as libraries, you could list these as dependencies for each application, and there need only be a single copy of those libraries on the client machine.

Setting up dependencies

Locate a published package from an available WebLogic Server in the left hand window and click 'Add'. Details about the depended-upon package are displayed in the right hand window. To remove a depended-upon package, select it in the right hand window, and click on 'Remove'.

Publishing a ZAC package

Once you have created a new package or updated details for a package that you have published previously, you are ready to publish the package to a WebLogic Server.

Select the package you wish to publish in the ZAC Publish Wizard main window. In the "Package" menu, select "Publish" if it is enabled. If you have multiple WebLogic Servers listed in the 'WebLogic Servers' panel, the second option "Publish to" will be enabled, which allows you to select the WebLogic Server to publish to.
If you select "Publish" the WebLogic Server is automatically chosen for you. This will be either the only server listed, or the last server that you published to or reverted from.
If you select "Publish to", you will need to select the address/port of the WebLogic Server to which you want to publish this package.
The first time you publish to a WebLogic Server, and each time you publish after you have restarted ZAC, you will be asked to supply a name and password. To publish, you must supply a username and password for the T3User that has "write" permission for the ACL weblogic.zac in the weblogic.properties file. If unset, this ACL defaults to granting only the "system" user with write (publish) privileges.

Supplying authorization for publishing
The progress of the publishing operation is shown in the "Publishing..." window. When complete, press "Close", or "Details >>" to review the details of the published package.

The publishing progress dialog

Reverting a ZAC Package

If you make changes to a local ZAC package before publishing it, you may revert the package to a version previously published on a WebLogic Server. Select the local package, and choose "Revert", or "Revert from" in the "Package" menu. If you are running more than one server you will need to select the later option in order to choose the server to revert from. If you choose "Revert", the server is chosen for you as either the only server that is listed, or the last server that you published to or reverted from.

Using the command line Publish Utility

You can use the command line Publish Utility to publish a ZAC package on the WebLogic Server, as an alternative to using the ZAC Publish Wizard. The Publish Utility is a stand alone java application that you may run from the command line, or invoke from a shell script. You configure the actions of the Publish Utility by supplying command line options. These options closely follow the parameters that you define in the ZAC Publish Wizard. Use the Publish Utility on the command line as follows:

  $ java weblogic.drp.admin.Publish [options]

Where the options are defined as follows:

-name zacPackage: (Required) The name for the ZAC package you are publishing, as it shall appear on the WebLogic Server. Note that the name should not contain any spaces.
-dir packageDir: (Required) The pathname of the top-level local directory that contains the entire contents for the ZAC package that you are creating and publishing. The contents of the directory, and all subdirectories are included in the new package.
-host hostname: (Optional) The host name of the WebLogic Server you are publishing to. This defaults to "localhost".
-port portnumber: (Optional) The port number of the WebLogic Server you are publishing to. This defaults to "7001".
-login username -password passwd: (Optional) You must specify a username and password to publish a package on a WebLogic Server that uses security controls for publish authentication. By default, this is set to the system user and password by the WebLogic Server. You may grant publish (write) privileges to a user or group by specifying an ACL in the weblogic.properties file. See Setting up WebLogic for publishing with ZAC (step 2) for details.
By default, the Publish Utility will attempt to publish the package without using a username and password. This will fail unless ZAC publish write privileges have been granted to everyone.
-verbose | -v: Causes the Publish Utility to print verbose messages about its operation.
-help: Prints a short summary of usage for the Publish Utility.

Connecting the Publish Wizard to other servers

When you start the Publish Wizard, it will connect automatically to the WebLogic Server running at the default location, and display it in the lower window pane. To discover other WebLogic Servers, select "Add" from the "server" menu to access the following dialog.

Adding more publish hosts to the Publish Wizard

The Add Server dialog

Updating a published ZAC package

Updating a previously published application is simple.

Start the Publish Wizard.
Select the package you want to update
Select "Open" from the "Package" menu.
Carry out the same steps as for creating and publishing a new package.

Importing a published ZAC package from another server

You can import a published package from one WebLogic Server and publish it on another WebLogic Server. At that point, the package becomes a separate copy at will not be updated if the original package is updated.

To import a published package:

Add the WebLogic Server host you wish to import from to the Publish Wizard's host list. See Connecting the Publish Wizard to other servers
Select the published package in the other WebLogic Server host.
Select "import" from the "Package" menu.
You will be asked where you wish to store the imported ZAC package files. Select an appropriate directory, and enter a directory name in the text box. A new directory will be created under that name in the current directory you have browsed to. If you do not specify a name, the operation will not be successful.

Storing the ZAC packaged files

Next, you are prompted for a name to save the ZAC package definition under. This should be saved in the default directory where you keep your ZAC package definitions. This is usually saved under the directory /weblogic_publish.

Saving the ZAC package definition

The imported package will apper under the "local package" list, under the name it was published with on the originating server.
You may now publish the package, as described under Publishing a ZAC package.

Removing a published ZAC package

The remove operation only removes the published application files themselves, including directory for the package that is stored in a package directory in the weblogic.zac.publishRoot.

Removing a package does not affect the WebLogic Server or the original files from which the package was published, nor will it remove local files from a ZAC client.

From the Server menu, choose Remove package.
Browse the WebLogic Server from which the package is to be removed.
Select the package and press the Choose button.

Creating an installer/bootstrap application

You can also use the ZAC Publish Wizard to create a set of native programs -- an installer and a bootstrap -- for various operating systems that become part of a published Java application.

The installer program is a native executable that installs your published Java program on the local machine; it may also install a JRE. It doesn't require a Java environment itself, so it can run out-of-the-box in the native OS. It's a little like an InstallShield for Java.

The bootstrap is also a native program; the user runs the bootstrap to invoke the published application. The bootstrap takes care of monitoring for updates, downloading and updating the user's application, and other administrative ZAC functions.

Installer/bootstrap programs can be created for the following OS types:

Win32 (Windows95/98 and Windows NT)
Solaris/SPARC
Linux/x86
DECUnix/Alpha
HPUX (HPUX 11)

Both the installer and the bootstrapper are small native, applications. You will need to create these for each type of operating system and CPU type that you expect your clients will use.

To create the installer/bootstrap executables in the Publish Wizard:

Start the Publish Wizard, and highlight the ZAC package for which you wish to create a bootstrapper installation program. You must have previously created a ZAC package for your application and published it on the WebLogic Server.
Select Create bootstrap app... from the Package menu.
Set the appropriate operating system and CPU type for this application. Choosing an OS and CPU will set some default values that you can adjust as necessary.

Setting OS details for the bootstrap
Enter the host and port of the publishing WebLogic Server. If you are preparing a bootstrapper application for a package installed on another server, you can find the available servers by pressing the Browse button.

Identifying the publishing WebLogic Server
Assign a name for the native bootstrapper executable. The bootstrapping process creates two applications: the installer package (usually very small) that the client downloads and runs initially, and the bootstrap that the user uses to invoke the published application each time he runs it. What you name in this step is the bootstrapper executable.

Assigning a name
Select one or more methods for finding and choosing a Java environment. You may depend on a locally available copy of the Microsoft or JavaSoft JVM, or you can load a JRE (Java Runtime Environment) that has been published as a ZAC package. Check the options that you want to be available to the client, and then order how those options should be processed by using the up-and-down arrows to the right.

Making the JRE available to the client app
If you selected Load own JRE, you will be prompted to locate the publishing WebLogic Server where the installer can find a published package of the JRE. For details on packaging your own JRE with ZAC, see the section Setting up a JRE later in this document.
Specify options for the Sun VM memory flags when if is initiated by the bootstrap application. The default values are specified here. You should set them accordingly if you application has special needs.

Setting memory options for the Sun VM
Enter the local directory on the client machine into which the bootstrap application should be installed when the user double-clicks the .exe file. The directory will be absolute if you begin the path with a slash (forward or backward depending upon the operating system for which you are publishing this bootstrap). If you choose the Start app in install directory option, the directory selected here is where the application will start from.

Setting a local client directory
Set the client permissions for the files associated with this package.

Setting access permissions for client files
If you are publishing for Windows, you will be asked to choose some special settings for Windows. You can install shortcuts for the Windows Start menu or desktop and you can set an icon for the bootstrapper package.

Setting Windows-specific options
Specify the behavior of the ZAC installation-bootstrap and the post-installation bootstrap. These options are defined as follows:

Update application

If this option is checked, the bootstrap executable will check for newly published versions of the ZAC application and update it if necessary. You may wish to disable this feature if one of these conditions is true:

You wish the client to run the application offline
You have embedded ZAC update functionality directly into the application using the ZAC API
You plan to generate another bootstrap executable for the purpose of updating the ZAC application (See Launch application option below)

Check all dependencies

If this option is checked, the bootstrap executable will check for newly published versions of the ZAC packages that this application depends upon. You may wish to disable this feature for similar reasons to those listed above.

Show progress window

If this option is checked, the bootstrap executable will display a meter indicating the progress of the download when the application updates. If you wish the update to be silent, you can uncheck this option.

Launch application

This option is usually checked. If this option is not checked, then the bootstrap executable will not launch the application. You might uncheck this option to create a bootstrap that will only update the application on the client machine. You could use such a bootstrap in conjunction with a bootstrap that only starts the application and does not update it.

Setting up bootstrapper options

Set a WebLogic username and password for access to this package. This should correspond to a WebLogic user that is on the access control list (ACL) for read permission to this application on the publishing WebLogic Server. Note that if you do not set an ACL for a published package, the permission to read defaults to the special group everyone and the permission to write (publish) the package defaults to the special administrative user system. That means that anyone can download your published package, but only a system-level user can publish or republish packages.

Setting the user and password for secure ZAC packages
If you expect your users to access the internet from behind a firewall, you should configure the bootstrap to ask for an HTTP proxy server through which it may access the WebLogic Server. It is a good idea to always leave this option checked, unless you know that your clients are not behind a firewall.

Configuring the bootstrapper to prompt for HTTP proxy details
Set the debug mode and verbosity of the application. This is useful while you are testing the deployment of your ZAC application from a client machine.

Setting debug mode
Review the bootstrap settings. Press the Generate button when completed.

Confirming your choices
From the Save As... window, select the location and name of the installation executable. The default name is based on the ZAC package name and the target OS; but you may call this executable file anything you like. You will deploy this executable to clients to install your application.

Saving the generated ZAC installation program

Packaging a JRE

You can wrap the entire JRE in a ZAC package and include it with your ZAC application. Including the JRE means that you do not need to make any assumptions about the end user's machine and you are assured that everything necessary for your application is provided, including the correct version of Java. The downside is that the initial download package is larger, and it may install the JRE even though there being another JRE present. This small initial inconvenience may be more desirable than causing installation problems for the user.

Before you begin

The following steps describe how you should make a ZAC package of the JRE. You can then include this ZAC package as a dependency of your application. Before you start the Publish Wizard, you should do the following:

Download the JRE install-shield. The JRE from JavaSoft can be downloaded from JavaSoft.
Install it on your development machine. In these instructions, we'll assume you have installed it in the directory c:\jre117.

Now start the Publish Wizard and continue the process.

Creating and publishing a ZAC JRE package.

Create the package type as "Library" and give it CLASSPATH "." (CLASSPATH doesn't matter in this case). Give it no dependencies.
Create a new package for the JRE. We recommend that you choose a name that reflects the OS and CPU type; for example, "JRE_117_win32_x86".
Enter a title and description for the JRE package. You can enter any title you wish.
Enter the package version as closely to the JRE version as possible. For example,

For JRE 1.1.7 enter '1' '1' '7'
For JRE 1.2.0 enter '1' '2' '0'

Entering the correct JRE version is important since the version string is used to determine the default local installation directory for the JRE. Using the same version number as the JRE version will minimize the chance that two separate ZAC packages will overwrite each other's JREs with incompatible versions. Of course, this is only used to determine the default install directory; the user ultimately decides where the JRE shall be installed.
You may optionally select a thumbnail image for the package.
Specify the top-level directory where you have previously installed the JRE. (In this example, we're using c:\jre117.)
Specify simply . (dot) as the CLASSPATH for your library.
Skip the other dialog screens and publish the package. Make sure that the publishing server is running before you try to publish.

After the publishing step is complete, you should see the new ZAC JRE package appear in the 'ZAC Publish Wizard' window.

Specifying a published JRE package for an application

Now that you have created your own JRE ZAC package (see section above), you need to add a dependency between it and your ZAC application. Here is how:

In the Publish Wizard, create an installer/bootstrap executable for your application, using the instructions in this document in the section Creating a bootstrap application.
During the create process, when you make choices on how to configure the Java Environment, you will see three choices that show the preference for choosing a JRE on the client user's host. You can order, select, or deselect these choices as illustrated on the right. Select Load own JRE as one of your VM choices and adjust its position in the preference list using the arrow buttons; then press the Next button.
When the bootstrap wizard asks where the JRE is published, provide the following:
- The hostname and port for the WebLogic Server where you published the ZAC JRE
- The ZAC name (e.g., "JRE_117_win32_x86") under which the JRE distribution is published
You can type in the path or Browse for the published package on the appropriate server in your server list.

Locating a published JRE

Press the Generate button, or proceed to the end of the bootstrap wizard.
Finally, choose a file name and path to save the installation executable on the publishing server. For example, \weblogic\public_html\MyAppInstall.exe saves the installer/bootstrapper into the default document root of a WebLogic Server host, where you can publish access to it from an HTML page.

The native installer will be small, probably about 250 KB for a Windows architecture. You can distribute it to clients however you like; for example, put a link to it on a web page, or attach it to an email.

Debugging and testing a published application

The WebLogic distribution contains native executables for running the ZAC bootstrap from the command line for Win32, Solaris, Linux, and DECUnix. The Windows version (zac.exe) is located in the bin/ directory; the non-Windows versions are located in the lib/{arch}/zac_{arch}/ directories. Each executable also has an _g version that can be used for verbose debugging.

Use the appropriate version of the command line bootstrapper to install or run a ZAC package. For example, you run the Windows version as shown here:

 $ zac.exe -name zacPackage options

The options are defined as follows:

-name zacPackage

Required. The name of the application to launch or download. For example:

 $ zac.exe -name ETrader

-host hostname

Hostname of the publishing WebLogic Server. This defaults to localhost. For example:

 $ zac.exe -name ETrader -host zac.weblogic.com

-port port

Port at which the publishing WebLogic Server is listening for login requests. Defaults to 7001. For example:

 $ zac.exe -name ETrader -host zac.weblogic.com -port 80

-proxy

Prompts for proxy information, according to the configuration set in the ZAC bootstrap wizard when the package was published.

-dir localDir

The local (client) directory where the ZAC application files are located. This defaults to the current working directory. The following example launches a ZAC application called ETrader:

 $ zac.exe -name ETrader -dir /usr/local/zac/

For this example, all files for the ETrader application and all of its dependencies will be stored in the subdirectories below /usr/local/zac/. The actual ZAC application ETrader is stored beneath this directory in another directory with the same name as the package, that is /usr/local/zac/ETrader/. The ZAC bootstrapper looks inside this directory for the OSD application manifest (index.osd).

-root

Start the Java ZAC application in the ZAC root directory. The default it to start the ZAC application in the current working directory.

-vm JVM type

Specifies the order of preference for locating a JVM

on the client's machine. Specify any combination of the characters "S","M",or "O" where the highest preference is on the left, and the characters represent:

S (Sun Java VM)
M (Microsoft VM)
O (Own VM. You provide your own JVM as a published ZAC package.)

If you use "O" in this argument, you must specify a JRE with the -jre flag.

-jre zacPackage

Required if you use "O" as an option for the -vm flag. Specifies a ZAC-published JRE.

-Dname=value

Specifies one or more Java system property to the Java VM when it is invoked by the bootstrapper.

--option

Pass the flag "-option" (with a single hyphen) to the Java application as it starts up.

-msnumber

Sets the JVM initial heap size for your client application (in megabytes).

-mxnumber

Sets the JVM maximum heap size for your client application (in megabytes).

-nolaunch

Updates a ZAC package without launching it.

-noquery

Disables the dialog that prompts the user for an alternate installation directory when the bootstrapper is run. By default this is enabled.

-noprogress

Disables the display of the download progress meter.

-noupdate

Launches a ZAC application without attempting to update it. Requires a previously successful download.

-verbose

Enables verbosity for classloading in the Sun JVM. This can be useful for tracking down problems with missing class dependencies on the client.

-help

View a list of the available options. Each option also has a shorthand version; These are indicated in the output of the -help command.

Change history

Release 4.0: Added ZAC executable for command line, client-side debugging for Linux, Windows, Solaris, and DECUnix.
Release 3.1: First release.; Fixed problem that was preventing ZAC bootstrapper from creating the install directory.; Removed all dependencies on com.sun.java.swing.* from zac.jar.; Introduced a new field to weblogic.zac.ZAC, public static final int ZAC_EXIT_RESTART. When a zac app is started with the native bootstrapper (supported for both Windows and Solaris), the application can System.exit(ZAC_EXIT_RESTART) and the bootstrapper will restart the VM anew, same as the first time.; Turned off class verification when invoking the JVM from the bootstrap process on UNIX. This makes it less likely that classes loaded by ZAC fail verification.; Publish Wizard now shows the publishing status log in a text window.