|
|
 |
 |
| Launching Your Application (Linux / Unix) |
Launching Your Application (Linux / Unix)
 |
|
|
 |
 |
 |
|
The Wrapper is shipped with a shell script (sh)
which can be used to reliably start and stop any Java application
controlled by the Java Service Wrapper.
First, please copy the following shell script from the Wrapper directory
into the bin directory of your application.
{WRAPPER_HOME}\src\bin\sh.script.in
|
Rename the script file to reflect your application name.
(Replace "MyApp" with the name of your application throughout this document.)
Now open the script into an editor.
We need to set the long and short names
to reflect that the script is being used to launch your application.
You will see two variables immediately after the header of the script.
APP_NAME and APP_LONG_NAME.
Suggested values for these variables are shown below.
APP_NAME="myapp"
APP_LONG_NAME="My Application"
|
The script should not require any additional modification.
However it does assume that
the wrapper executable is placed in the same directory,
and also assume that
the wrapper.conf
file is placed within a conf directory
(one level up, ../conf/wrapper.conf).
If you wish to place either of these files someplace else,
the WRAPPER_CONF variable in the script
will require appropriate modification.
|
NOTE
|  |
Important! Before proceeding,
please make sure that both the script and the
wrapper
executable have their executable bit set.
|
|
NOTE
|  |
The shell script (sh) will attempt to create
a PID file
in the /var/run directory.
If the user used to launch the Wrapper does not have permission to
write to this directory then this will result in an error.
An alternative that will work in most cases is to write the PID file
to the same directory where the Wrapper executable is located.
To make this change, edit the sh
script and change the following line:
to:
|
|
 |
 |
|
Start the application:
The application can now be run by simply executing
bin/myapp console.
Because of the way the Wrapper script sets its current directory,
it is not necessary to run this script from within the
bin directory.
/usr/lib/myapp/bin/myapp console
Running My Application...
wrapper | --> Wrapper Started as Console
wrapper | Launching a JVM...
jvm 1 | Wrapper (Version 3.x.x)
jvm 1 |
|
When running using the console command,
output from the JVM will be visible in the console.
Stop the application:
The application can be terminated by pressing CTRL-C in the console (command window).
This will cause the Wrapper to shut down the application cleanly.
Standard Daemon scripts:
As you will see if you omit a command,
the scripts shipped with the Wrapper are fairly standard daemon scripts.
They accept console,
start,
stop,
restart,
status, and
dump commands.
The start,
stop, and
restart commands are common
to most daemon scripts and are used to control the Wrapper and
its application as a daemon process.
The status command
can be used to find out whether or not the Wrapper is currently running.
The console command
will launch the Wrapper in the current shell, making it
possible to kill the application with CTRL-C.
The final command, dump, will send a
kill -3 signal to the Wrapper
causing the its JVM to do a full thread dump.
|
 |
 |
|
The application can be run as a detached daemon process by
executing the script using the start command.
/usr/lib/myapp/bin/myapp start
Running My Application...
|
When running using the start
command, output from the JVM will only be visible by viewing the
wrapper.log file using
tail -f wrapper.log
Because the application is running as a detached process,
it can not be terminated using CTRL-C
and will continue to run even if the console is closed.
To stop the application, rerun the script using the stop command.
/usr/lib/myapp/bin/myapp stop
Stopping Test Wrapper Sample Application...
Stopped Test Wrapper Sample Application.
|
|
 |
 |
|
Introduced in the Wrapper version 3.4.0,
the script provides a way to embed the Wrapper (and finally your application).
The script will automatically detect your OS -
on Linux platforms also some distributions -
and perform the steps necessary to install the Wrapper script
into the initialization process of your OS.
$ sudo bin/testwrapper install
[sudo] password for tanuki:
Detected Ubuntu:
Installing service testwrapper from current directory /home/tanuki/wrapper/bin
Adding system startup for /etc/init.d/testwrapper ...
/etc/rc0.d/K20testwrapper -> ../init.d/testwrapper
/etc/rc1.d/K20testwrapper -> ../init.d/testwrapper
/etc/rc6.d/K20testwrapper -> ../init.d/testwrapper
/etc/rc2.d/S20testwrapper -> ../init.d/testwrapper
/etc/rc3.d/S20testwrapper -> ../init.d/testwrapper
/etc/rc4.d/S20testwrapper -> ../init.d/testwrapper
/etc/rc5.d/S20testwrapper -> ../init.d/testwrapper
|
As the script installs itself into your OS,
it is necessary to run the install (and uninstall) option as a root user!
For freebsd and MacOSX users, the script provides a default configuration file
how launchd or initd
will handle the script during the boot process.
However it is possible to customize this step just
by placing the configuration file into the bin directory.
For MacOSX, the file name of this file has to be {filename of your script}.plist.
For freebsd, {filename of your script}.install.
For example if the script is called "testwrapper"
it would look for respectively "testwrapper.plist" on MacOSX, and
"testwrapper.install" on freebsd.
If you wish to uninstall/remove the Wrapper from the system initialization,
run the script (as a root user!) with passing the action parameter "remove".
This will first stop the running wrapper application and finally clean itself from initialization.
$ sudo bin/testwrapper remove
[sudo] password for tanuki:
Stopping Test Wrapper Sample Application...
Stopped Test Wrapper Sample Application.
Detected Ubuntu:
Removing service testwrapper from current directory /home/tanuki/wrapper/bin
Removing any system startup links for /etc/init.d/testwrapper ...
/etc/rc0.d/K20testwrapper
/etc/rc1.d/K20testwrapper
/etc/rc2.d/S20testwrapper
/etc/rc3.d/S20testwrapper
/etc/rc4.d/S20testwrapper
/etc/rc5.d/S20testwrapper
/etc/rc6.d/K20testwrapper
|
Installing older versions of the Wrapper prior to 3.4.0 has to be done manually.
If your platform is not included,
please read over those that have been included and adapt as necessary.
Please post what you come up with to the
wrapper-user@sourceforge.net
mailing list and I will be more than happy to include them in the next release.
|
 |
 |
|
As an alternative to using the scripts shipped with the Java Service Wrapper,
you may choose to launch the Wrapper directly.
If the wrapper executable is launched
without any parameters, the following usage output will be displayed.
/usr/lib/myapp/bin/wrapper
Wrapper (Version 3.n.n) http://wrapper.tanukisoftware.org
Usage:
wrapper <command> <configuration file> [configuration properties] [...]
wrapper <configuration file> [configuration properties] [...]
(<command> implicitly '-c')
wrapper <command>
(<configuration file> implicitly 'wrapper.conf')
wrapper
(<command> implicitly '-c' and <configuration file> 'wrapper.conf')
where <command> can be one of:
-c --console run as a Console application
-? --help print this help message
<configuration file> is the wrapper.conf to use. Name must be absolute or relative
to the location of wrapper
[configuration properties] are configuration name-value pairs which override values
in wrapper.conf. For example:
wrapper.debug=TRUE
|
To run the Wrapper in a shell,
you would specify the -c command,
followed by the
wrapper.conf file.
The location of the wrapper.conf file
can be an absolute or relative location.
If a relative path is used, the path is always relative to the location of the
wrapper file, not the current directory.
/usr/lib/myapp/bin/wrapper -c ..\conf\wrapper.conf
|
To launch the application a daemon process (Using the shell script is recommended):
/usr/lib/myapp/bin/wrapper -c ..\conf\wrapper.conf wrapper.daemonize=TRUE
|
|
|
|
|
 | If you notice something that is incorrect, missing, or simply feel that some part of this page could be explained better, feel free to log in and add a comment. You will need to register before you can log on. |
|
|  |
|
 |
| |