
Hosted by:
|
|  |
What is the Java Service Wrapper?
 |
NOTE
|  |
Over the past year, the Java Service Wrapper has seen a huge jump in
its install base. From our logs, we see that an increasing number
of both large and small companies are showing interest in the Wrapper.
We would like to thank all of our users for the great feedback which
has helped us to continuously improve the Wrapper over time.
A large percentage of our user base is using the Wrapper to support
commercial applications and or commercial infrastructure. We urge
all of our users to please look at the value that the Wrapper is
providing to your organization. The Wrapper team develops and
maintains the Wrapper on a volunteer basis. But the time and effort
involved is real. Please help us to keep the Wrapper project alive,
free, and growing, by showing your appreciation and support for the
project with a donation to the team.
Sincerely,
The Java Service Wrapper team.
|
|
 |
The Java Service Wrapper is an application which has evolved out of a
desire to solve a number of problems common to many Java applications:
 |
 |
The Wrapper makes it possible to install a Java Application as a
Windows NT Service. The scripts provided with the Wrapper also
make it very easy to install those same Java Applications as
daemon processes on UNIX systems.
The Wrapper correctly handles user log outs under Windows, service
dependencies, and the ability to run services which interact with
the desktop.
|
 |
 |
Application Reliability. As the use of Java expands, applications have
been written to provide a variety of mission critical services. These
services must be able to provide a high level of reliability. In an
ideal world, only software which is 100% bug free will ever be released
and installed. However, history has shown this not to be the case.
Almost every application suffers from quality issues at one point or
another during their life-cycle. Applications hang, crash, run out of
memory or suffer from any number of problems. Where possible, problems
are fixed quickly without significant service outages. There are times,
however, when fixing a problem can be prohibitively expensive or
impossible to solve in a short time period.
The Wrapper monitors a JVM process and automatically restarts it if it
that the JVM has crashed or hung. This process takes just a few seconds
once the Wrapper has decided there is a problem. There is also a way to
configure the Wrapper to
monitor the console output of a JVM and react to certain strings by
restarting or shutting down the JVM.
While these features will not make every problem go away, they will help
you to sleep easier knowing that if there is a problem, the Wrapper will
be there to keep things up and running until you can get into the office
to check the logs. Say goodbye to that pager!!
|
 |
 |
Write once run everywhere configuration. Java has been marketed as a
"Write Once, Run Everywhere" programming language. While this is true
for many aspects of an application, the developer is often plagued with
having to write complicated, platform specific scripts which are tasked
with building up class paths and collecting other system information
necessary to launch an application.
The Java Service Wrapper helps to relieve the developer of this task
by providing a set of scripts for a wide range of platforms that can be
used as is to launch almost any Java Application controlled by the
Wrapper.
The Wrapper moves all JVM configuration into a platform independent
configuration file. See the
integration examples for details.
|
 |
 |
The Wrapper provides a way for a Java Application to request that
its own JVM be restarted. This can be useful in a number of cases.
Applications may wish to restart after having had their configuration
files modified. Or the application may simply need to be restarted
to avoid problems with a memory or resource leak of some kind.
JVM restarts are triggered by calling
WrapperManager.restart(). See the
Javadocs for more details.
|
 |
 |
The Wrapper provides a wide range of configuration properties which can
be used to configure the JVM in any way possible from the command line.
The Wrapper configuration file also provides a number of properties to
allow you configure things like logging and how the Wrapper is installed
as a service.
See the Configuration Properties
section for details on what is possible. Be sure you have read over
the integration section before
jumping into the configuration file.
|
 |
 |
By using the Wrapper's standard scripts, and relative paths in the
configuration file, it is usually possible to create an application
which requires no further installation than simply expanding an
archive file into a directory of the user's choice.
|
 |
 |
While the Wrapper does not attempt to, not should it, replace any
of the great logging tools available, it does provide a number of
properties to configure how stdout and stderr output to the JVM console
is handled. This output can be logged to any combination of the console,
a file, or the Event Log (Windows) or syslog (UNIX).
Logging the output to the JVM console can be critical to tracking down
problems with an application. When a JVM is being run as a service
under Windows, or as a daemon under UNIX, the console output is lost.
Most Logging tools will only log output specifically directed to the
logger. This does not include OutOfMemory errors or fatal JVM heap
dumps.
See the Logging Configuration
section for further details.
|
|
 |
The Wrapper is known to work with the Sun, IBM, Blackdown and BEA WebLogic
JRockit JVMs without any problems. If you get a chance to test any other
JVMs, please be sure and let us know the results.
NOTE
|  |
The Wrapper can be used with 1.2.x versions however some functions are disabled
due to this version of Java's lack of support for shutdown hooks. Shutdown
hooks were implemented with the 1.3.0 release of Java.
|
|
 |
The Wrapper can be build from source without modification on Windows, Linux,
Solaris, AIX, HP-UX, Macintosh OS X, DEC OSF1, FreeBSD, and SGI Irix systems.
If you have tested the Wrapper build on any other platforms, please let us
know and we will add them to the list.
|
|
by Leif Mortenson
|
|