user manual

124 BES Developer’s Guide
Exception handling
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.
Exception handling
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 resource-ref 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-ref-types like JMS and Mail should be configured and
deployed using the relevant vendor tools for these products.
Other features
Borland Enterprise Server includes a number of extra features in the VisiClient
container in addition to the requirements for the J2EE specification. These
include:
■
User Transaction interface: This is available in the java:comp/env name
space and can be looked up using JNDI. It supports transaction
demarcation, and propagation.
■
Client Verify Tool: This runs on standalone client JARs or client JARs
embedded in an EAR file. The verify tool enforces the following rules:
■
The manifest file in the client JAR has the main class specified.
■
The JAR/EAR is valid (it has the correct required manifest entries).