web server - Borland Technical Publications

Use of Manifest files
Use of Manifest files
Exception handling
VisiClient container relies on the presence of a manifest file to obtain information about
launching an application. The manifest file should be saved in the META-INF
subdirectory of the client archive. The relevant attributes in the manifest file for the
VisiClient container are:
■
■
The main class to be launched by the container on startup. This is an application
entry point which must be present in the manifest file.
The classpath of the dependencies of the main class. If the client-jar is selfcontained,
or if dependencies are specified using the system CLASSPATH during
application launch, this attribute can be ignored.
Example of a Manifest file
An example of a Manifest file is shown below.
Manifest-Version: 1.0
Main-Class: SortClient
Class-Path:
This example shows the container will execute by loading the main method of the class
specified in the Main-Class attribute of the Manifest file. In this example it is SortClient.
The container expects to have a method with the following signature in this class:
public static void main(String[ ] args) throws Exception {...}
The container will report an error and exit if it doesn't find the main method. The client
verify utility, which comes with VisiClient, tries to locate a main class and reports an
error if it doesn't find one.
Application client code is responsible for taking care of any exceptions that are
generated during the program execution. Any unhandled exceptions are caught by the
container which will log them and terminate the Java virtual machine process.
Using resource-reference factory types
The client application deployed in a client container can use the VisiTransact JDBC
connection pooling and Prepared Statement re-use facilities. Refer to the Deployment,
and Transaction chapters of the Borland Enterprise Server Developer's Guide for
details about configuration and deployment. Client applications in Borland Enterprise
Server can use JDBC 2-based datasources.
Note that just like javax.sql.DataSource (which is one of the possible res-ref-types)
VisiClient allows the application to use URL, JMS, and Mail factories as the resourceref
types.
java.net.url and java_mail.session factories are deployed in the in-process local JNDI
subcontext that resides in the client container virtual machine on startup. Other res-reftypes
like JMS and Mail should be configured and deployed using the relevant vendor
tools for these products.
104 BES Developer’s Guide