Each application that is available on a DSJ server is described by a
.app file. The file contains single-value properties and
lists denoted by tags. The properties and the tagged lists may appear in
any order in the file.
In the file, all leading whitespace (spaces and tabs) are ignored. Lines that begin with a semicolon are considered comments and ignored.
Each property is followed by the equal sign (=) and its value, if any, on a single line.
Tags end with a colon (:). Every line between a tag line and the next tag line (or the end of the file), that is not a recognized property, is part of the list for that tag. Leading white space and blank lines are ignored.
These are the .app file properties:
These are the .app file tags:
The secondary preferred JRE on which to run the application. If an application has an AlternateJRE, it should also have a PreferredJRE. For a detail description of how the server handles JREs, see Specifying JREs.
By default, no preferred JREs are specified.
The list of users, IP addresses, IP address ranges, and user groups that can access the application. If either the user name or IP address of the client matches one of those listed, the client can access the application.
To restrict access to a particular user on a specific IP address, you must create a group file.
To allow unrestricted access to an application, leave the list empty, or omit the tag entirely.
By default, the list of authorized accessors is empty; anyone may access the application.
The hostname (or IP address) and port number of the servers that provide service to the application. This list is transmitted to the client twice, sometimes by the same server. The first time, the list is used as the list of servers to contact for long-term service. The second time, it is the list of alternate servers to contact if the long-term server goes down.
The list usually includes the current server, assuming that the application is installed on the server, but this is not required.
The hostname is relative to the client machine. The hostname and port number are separated with a comma.
You may also specify server group files by preceding the filename with the "@" character.
Whenever an application is added through the server console, the
localhost machine on the default port is added to the list:
localhost, 707
This is useful for testing, but in most cases, you donÆt want the
client to waste time checking itself. Once the application is out of the
test phase, you should remove the localhost line.
The following entries list all four DSJ servers that are online in
the company domain mycompany.com, all on the default port:
Available Servers: jserver1.mycompany.com, 707 jserver2.mycompany.com, 707 jserver3.mycompany.com, 707 jserver4.mycompany.com, 707
Note that for clients inside the companyÆs domain, itÆs not required to specify the domain name. But if you allow outside access, the domain name is required, so itÆs better to use the full hostname.
If these
four servers always have the same applications installed on them, you
can create a server group file, for example MainServers,
and then specify that file in the Available Servers list
instead:
Available Servers: @MainServers
The partial class path for the application. Do not include the core
system class libraries like rt.jar or
classes.zip; those classes are always assumed to be
available. This property is used when the application is first installed
to calculate the package dependencies. It is ignored from then on,
unless you recalculate the package dependencies.
Entries in the class path are relative to the DSJ serverÆs current
directory--the current directory at the time of startup. If you use the
dsjserver.bat file to start the DSJ server, this is usually
the root install directory.
None. You must supply a value for this property.
For the Hello sample application, created under the directory
c:\jbuilder\myclasses:
Classpath=c:\jbuilder\myclasses;jgl.zip;jbcl.zip
Command line arguments that you always want sent to the application during startup. The user may also specify arguments when the client starts the application.
By default, no arguments are sent; the property is blank.
Suppose your application supports different languages. For the French extension file for your application, you specify the following argument:
CommandLineArguments=/language=french
By using an extension file, the argument is used automatically, but only for those users running a French operating system.
A description of the application that appears in the Available Applications dialog box when the user starts the DSJ client without requesting a specific application.
The default description is blank.
External files that required by the application. These files will be downloaded to the client before the application is executed. Each file is listed as follows:
<name on server> <name on client> <true | false>
The true/false value controls whether the
file should be added to the applicationÆs class path. It is optional;
the default is false.
By default, the extra files list is empty.
Suppose your Mermaid application has a splash screen that you expect
to find in the \data subdirectory. The
splash.gif file is stored on the server in the directory
c:\javapps\mermaid\data, so you use the following Extra
Files list:
Extra Files: c:\javapps\mermaid\data\splash.gif data\splash.gif
Before the application starts, the client will download the file from
the server, creating the \data subdirectory if necessary.
The main class of the application. The static main()
method of the class is executed to start the application.
None. You must supply a value for this property.
For the Hello sample application:
Mainclass=Hello.Hello
The name of the application. Whenever the client specifies the name of an application, this is the name that is used. This name appears in the Available Applications dialog box when the user starts the DSJ client without requesting a specific application. The name is case-sensitive.
.app file, but this is not required.
None. You must supply a value for this property.
For the Hello sample application:
Name=Hello
A list of packages that the application might use. When the server calculates this list, it includes all the packages in the class path--it does not attempt to determine whether the application actually uses any classes in each package. So it is quite likely that the list includes packages the application never uses, which is safer but slightly wasteful.
You can manually prune the generated list. This makes the preload cache footprint smaller (which means a faster download), and the serving of resources on-demand slightly faster. But if you leave out a required package, the application will fail.
Each package is listed by name and version date.
None. If the tag is missing or the list is empty, the server will recalculate the package dependencies for the application during startup.
The preferred JRE on which to run the application. You may specify a second choice with the AlternateJRE property. For a detail description of how the server handles JREs, see Specifying JREs.
If the value is prefixed by the "!" character, it is ignored. This way, both a preferred and required JRE can be stored, but only one (or neither) can be active at any time.
By default, no preferred JREs are specified.
The JRE that the application requires to run. For a detail description of how the server handles JREs, see Specifying JREs.
If the value is prefixed by the "!" character, it is ignored. This way, both a required and preferred JRE can be stored, but only one (or neither) can be active at any time.
By default, no required JRE is specified.
This is a true/false property that
determines whether the application uses the console. It is used when the
server instructs the client to restart. If the application uses the
console, the client will restart using jre, which runs in a
command prompt window; if not, the client will restart using
jrew, which does not display the console window.
The default setting is false; no console is used for
restarts.
The version number of the application. This number is displayed with the application name in the Available Applications dialog box when the user starts the DSJ client without requesting a specific application, and is used when the client requests a specific version of an application.
The DSJ server does not use the version number for determinining the latest version of an application; it uses the VersionDate instead.
By default, the version is blank.
The version date of the application. The date is used to determine the latest version of the application.
The date may be in any of the following generally recognized date formats:
March 23, 1998 23-Mar-1998
None, although when adding a new application through the server console, the new Application dialog box will supply the current date as a default value. You must specify a version date for an application.