YAJSW Configuration Properties

General Notes

 "\"  is the escape character. For file paths it is preferable to use "/".
If back-slash is required use "\\".

"," is used as list delimiter. If required you will have to escape it (eg write "\,")

For windows %SOME_ENV_VAR% will not work. You will have to use ${SOME_ENV_VAR}

Example:

          wrapper.java.additional.2=-Xdebug -Xrunjdwp:transport=dt_socket\,server=y\,suspend=y\,address=1044
wrapper.java.library.path.2=${JNA_HOME}/bin
wrapper.java.library.path.1=.\\bin

Accessing Environment Properties

If you defined OS environment variables you may access these directly within the configuration.

Example (Windows)

set wrapper_java_path=c:/java/jdk1.5.0

          wrapper.java=${wrapper_java_path}/bin/java.exe

Includes

If a property is named "include" and the value of that property is the name of a file on the disk, that file will be included into the configuration.

Example:

tomcat_start.conf:

include=tomcat_base.conf
wrapper.app.parameter.1=start
wrapper.stop=tomcat_stop.conf

tomcat_stop.conf:

include=tomcat_base.conf
wrapper.app.parameter.1=stop


Conditional Includes

Some applications require different configurations for different platforms, operating systems or languages. This can be achieved by creating platform specific includes. As example, our application requires
us to set the native library depending on the operating system and architecture. We determine these from the System.properties "os.name" and "os.arch". Per supported os and arch we create a configuration file
named <os.name>.<arch>.conf. Within our configuration file we define include as follows:

          include=${os.name}.${os.arch}.conf

The file
          Windows XP.x86.conf

defines the platform specific library
           wrapper.java.additional.1=-Dlib=w86.dll

Whereas the file
           Linux.x86.conf

defines
           wrapper.java.additional.1=-Dlib=l86.iso


Groovy Expressions

Alternatively to conditional includes, one may use groovy scripts.
${ expr } are interpreted as groovy expressions which are evaluated.

Example:


wrapper.java.library.path.1=${ if  ("${os.name}".toLowerCase().startsWith("windows")) "libw.dll"; else if  ("${os.name}".toLowerCase().startsWith("linux")) "libl" }

YAJSW includes a util binding for getting user input:

util.inquireCLI(String) prints the given message to the wrapper process console and waits for the user input.

util.inquireTryIcon(String) displays the given message on the system tray icon and waits for the user input.The user will have to click the respond button in the tray icon menue and enter the required data.

Example:

wrapper.ntservice.password = ${util.inquireCLI('please enter password for winods service user')}

wrapper.app.password = ${util.inquireTryIcon('please enter password for winods service user')}

Multiple Lines

For readability properties may be formatted on multiple lines.

Example:


wrapper.script.ABORT=scripts/sendMail.gv
wrapper.script.ABORT.args=somebody@help.com,"process aborted","process took a long time\n \
 it had to be aborted\n \
please do something"

wrapper.java.library.path.1=${ \
      if  ("${os.name}".toLowerCase().startsWith("windows")) \
         "libw.dll"; \
      else if  ("${os.name}".toLowerCase().startsWith("linux")) \
         "libl"; \
      }

Lists and arrays

Commons Configuration has the ability to return easily a list of values. For example a properties file can contain a list of comma separated values

NOTE: currently please do not use lists. wrapper.java.classpath.1=x.jar, y.jar will not work !. This will be supported in a later version.

Multiple Value Properties

Multiple Value Properties are configuration properties which require multiple inputs such as wrapper.app.parameter.<n>
In the tanukisoftware wrapper <n> must be a number and numbers must be sequential.
For YAJSW <n> may be a number or string. The numbers do not have to be sequential. Nor do they need to be unique.
Ordering is done by the natural alpha numeric ordering. In case of parameters with the same key ordering is random.

Example
wrapper.java.classpath.1=a.jar
wrapper.java.classpath.1=b.jar
wrapper.java.classpath.5=c.jar
wrapper.java.classpath.ab5=d.jar
wrapper.java.classpath.ab12=e.jar

will result in

-classpath b.jar;a.jar;c.jar;d.jar;e.jar

NOTE:
The colors in the sequel are defined as follows:

Implemented
Currently undecided
Currently not Implemented. May be implemented in a future release
Currently not Implemented. Will probably NOT be implemented in future.
The meaning of the property has changed.
Minor  change to the meaning of the property.

New  Configuration Properties

Property Name
Comments   
wrapper.java.app.jar In case a java application is started with the "-jar" option, this property specifies the jar file to execute.

Example:
wrapper.java.app.jar=wrapper.jar
wrapper.app.parameter.1=-c
wrapper.app.parameter.2=wrapper.conf

This will start the following java application : "java -jar wrapper.jar -c wrapper.conf"
wrapper.java.app.mainclass The main class of the application.
 This is not required in the tanuki software wrapper. For compatibility it is also not required when excuting bat/wrapper.bat which is compatible with the original wrapper.exe.
However passing the main class as an application argument can be confusing. I find that it is better to add the main class to the configuration properties.
wrapper.groovy Start a groovy script as an application

Example:
wrapper.groovy = myWebServices.gv
wrapper.image Native image to start.

Example:
wrapper.image=notepad.exe
wrapper.stop.conf There are applications such as tomcat which are stopped by invoking a program instead of calling System.exit() from within the application.
If this property is defined and the specified conf file is found, the application is stopped by calling the application defined by the given configuration file.

If the application is not stopped within the given timeout it is killed.

Example:
within the file tomcat.conf:
          wrapper.stop=conf/tomcat.stop.conf
          wrapper.app.parameter.1=start

the file tomcat.stop.conf:
        # overwrite the first argument
        wrapper.app.parameter.1=stop
        # this is a stopper configuration
        wrapper.stopper = true
        wrapper.console.title = ShutdownTomcat
        # for all other properties: use the same as for stating tomcat
        include = tomcat.conf

Default: no stopper configuration.
wrapper.stopper This property indicates that this is a stopper application, for stopping another application.
It  overrides properties as following and removes all conditions, scripts, timers, ....

wrapper.exit_on_main_terminate = 0
wrapper.on_exit.default = SHUTDOWN

Example
      wrapper.stopper = true

Default: false
wrapper.exit_on_main_terminate There are java applications, such as servers which run a separate thread. The application should continue running even if the main method terminated.
Other applications should terminate with an exit code.

This property defines the exit code.
If this property is > -1, System.exit(exit code) will be called once the main method terminates.

Example:
    wrapper.exit_on_main_terminate = -1

Default: -1, eg the application will not be terminated once the main method terminates
wrapper.exit_on_main_exception The main method may throw an exception. In this case the application can be terminated with an exit code or may continue to run.

This property defines the exit code in case of an exception.
If this property is > -1 System.exit(exit code) will be called if an exception is thrown.

Default: 999, eg the application will terminate with exit code 999 in case the main method throws an exception.
wrapper.daemon.dir For Posix OS: Directory in which to create and execute daemon init scripts.
Default: /etc/init.d
wrapper.daemon.pid.dir For Posix OS: Directory where to store the wrapper.pidfile, if this property is not defined, in case the application is started as a daemon.
Default: /var/run
wrapper.daemon.template For Posix OS: Velocity template file for generating daemon init scripts.
Default: <templates>/daemon.vm
wrapper.daemon.run_level_dir.<n> For Posix OS: Directory in which to create K... and S... links
Default: <wrapper.daemon.dir>/rc5.d

Example 1:

wrapper.daemon.run_
level_dir=/etc/rc5.d

will create the links

/etc/rc5.d/K99<wrapper.ntservice.name>
/etc/rc5.d/S99<wrapper.ntservice.name>

Example 2:

wrapper.daemon.run_level_dir.1=/etc/rc5.d
wrapper.daemon.s_order.1=88
wrapper.daemon.2875747287574728757472875747wrapper.shutdown.timeout has no effectk_order.1=88
wrapper.daemon.run_level_dir.2=/etc/rc4.d
wrapper.daemon.s_order.2=99

will create the links

/etc/rc5.d/K88<wrapper.ntservice.name>
/etc/rc5.d/S88<wrapper.ntservice.name>
/etc/rc4.d/S99<wrapper.ntservice.name>

wrapper.daemon.k_order.<n> For Posix OS: the link K...  will be named: K<wrapper.daemon.k_order><wrapper.ntservice.name>
Default: 99
wrapper.daemon.s_order.<n> For Posix OS: the link S...  will be named: S<wrapper.daemon.s_order><wrapper.ntservice.name>
Default: 99
wrapper.launchd.dir For Mac OS X daemons: Directory into which the launchd plist file is copied.
Default: ~Library/LaunchAgents
wrapper.plist.template For Mac OS X daemons: Velocity template file for generating a launchd plist file.
Default: <templates>/launchd.plist.vm
wrapper.exit_code.stop Exit Code of the application when the stop method has been succesfully invoked.
Default: 0
wrapper.exit_code.kill Exit Code of the application when the stop method did not stop the application within the given timeout and the application termination is forced.
Default: 999
wrapper.exit_code.fatal Exit Code of the application in case it could not be started or in case the main method terminated with an Exception
Default: 999
wrapper.control Depending on the application there are use cases where the wrapper process should continue to run, even when the application is stopped and vice versa. For example in case the wrapper continues to run independently of the application the application may be restarted by jmx. In other cases such as important server applications you may want to shutdown the wrapper due to an update of a script without stopping the application. The wrapper may then be restarted so that it "reconnects" to the application.

With the this property one may control how the wrapper and the application are coupeled.

LOOSE :                    application will continue running when the controller is terminated and vice versa
TIGHT:                      application will terminate if controller terminates and vice versa
WRAPPER:               controller will be terminated if the application terminates. Application will not be terminated if the controller is terminated
APPLICATION:        application will be terminated if the contrloler terminates. Controller will not be terminated if the application is terminated

In case a timer or condition is active, the controller is not stopped. In this cases you may consider calling System.exit() from within a condition script.

Default: TIGHT
wrapper.windows.cluster.script
wrapper.windows.cluster.script.args
wrapper.windows.cluster.groups
Name of a groovy script which is called whenever the owner of the group of the cluster changes.
By calling System.getenv("COMPUTERNAME").equals(process.cluster.activeNode) within the script one may check if the current node is the active node.

In case the script should be invoked only for specific groups one may add the list of groups to the property wrapper.windows.cluster.groups

NOTE: do not define this property if the wrapper is not running on a cluster, as this will crash the JVM.
NOTE: this property is only valid for windows OS and requires ClusApi.dll.
NOTE: the first call to WrappedProcess.start() will not start the application, but will execute the script. One may thus make sure that the application is startedonly on the active node.
wrapper.codebase Root folder for classpath files and for resource files.
Supports file systems supported by commons VFS

Examples:
wrapper.codebase =webdav://somehost:8080/dist
wrapper.codebase =c:/dist
wrapper.cache Cache directory to which files are copied.

Example:
wrapper.cache=c:/yajsw_cache
wrapper.cache.local Indicates if local files are copied to wrapper.cache

Default: false

Example:
wrapper.cache.local = true
wrapper.resource.<n> Defines files which should be copied to the cache:

Examples:

wrapper.resource.1=images/image1.jpg
wrapper.resource.2=conf/test.properties

New Optional Configuration Properties

Property Name
Comments   
wrapper.tmp.path path for storing temporary files. Default is /tmp
wrapper.console.visible Boolean (true, false) indicating if the console of the application should be visible.
Default: false
wrapper.id |
wrapper.script.<state>
wrapper.script.<state>.args
The file name of the script to be executed when the processing state is changed to the given state.
<state> :: START | RUN | RESTART | STOP | ABORT | SHUTDOWN | IDLE

State changes are as follows:

IDLE -> START -> ABORT -> IDLE
                            -> RUN -> ABORT -> IDLE
                                          -> STOP -> IDLE
                                          -> RESTART -> RUN

IDLE initial state
START WrappedProcess.start() executed
RUN Application successfully launched
ABORT unintentional stop of the application:

application crashed and will not be restarted
missing application ping
application did not start
application did not log on
max restarts
STOP Intentional stop of the application:

WrappedProcess.stop()
WrapperManager.stop()
WrapperExe terminated
WrappedService.stop()
RESTART Intentional or unintentional restart of the application

WrappedProcess.restart()
WrapperManger.restart()
wrapper.on_exit.<n>=RESTART
wrapper.filter.action.<n>=RESTART
SHUTDOWN WrapperExe terminates
WrappedService terminates

NOTE: in case of shutdown we give the script 5 sec to execute before Runtime.halt() is called. This should be sufficient to send a last mail or snmp trap.


The following parameters are passed to the script:
<id> <state> <count> <pid> <exit-code><line>
where <id> is set to <state>, <count> is the current number of restarts, <pid> is the last available process id and exit code is the last available exit code
Example:
wrapper.script.ABORT=scripts/sendMail.gv
wrapper.script.ABORT.args=somebody@help.com,"process aborted","process aborted"
wrapper.filter.script.<n>
wrapper.filter.script.<n>.args
The file name of the script to be executed when the filter is triggered.
The following parameters are passed to the script:
<id> <state> <count> <pid> <exit-code> <line>
where <state> is "RUNNING", <id> is set to <n>, <count> is the current number of restarts, <pid> is the last available process id and exit code is the last available exit code

Currently shell scripts (assuming ending with .bat or .sh) and groovy scripts (ending with .gv or .groovy) are supported.
Within groovy the following bindings are available: id, state, count, pid, exitCode, line, wrappedProcess

args is a list of "," separated string arguments which are passed to the script

Example:
wrapper.filter.trigger.exception=Exception
wrapper.filter.script.exception=sendmail.gv
wrapper.filter.script.exception.args=somebody@help.com,"process restart","process threw an exection $process.triggerLine -> restarting"
wrapper.filter.action.exception=RESTART
wrapper.filter.trigger-regex.<n> Similar to "wrapper.filter.trigger.<n>" except that the trigger used is a regular expression.
wrapper.timer.cron.<cmd> <cmd> :: START | STOP | RESTART

Timer command for controlling process execution with a cron expression.
RESTART:  Restarts the process at the trigger time. If the process is running it is stopped and then restarted. Otherwise the process is started.
START: Starts the process if it is not running at the trigger time. If the wrapper.timer.cron.START property is missing the process is started immediatly.
STOP: Stops the process if it is running at the trigger time.

Example:
wrapper.timer.RESTART.cron=* * 0/12 * * ?

Starts the process immediatly and restart the process daily at 00:00 and 12:00 h.

Note that WrapperManger.stop() and WrappedJavaProcess.stop() will stop the application but will not stop the timer.
To stop the timer use WrapperManger.stopTimer() or WrappedJavaProcess.stopTimer()

Note that this is just a "dumb time trigger". It does not consider if the application is startable or if it has been restarted by a filter or by the user.
wrapper.timer.simple.<cmd>.<prop> <cmd> :: START | STOP | RESTART
<prop> : FIRST | COUNT | INTERVAL

<cmd> has the same meaning as for the "cron" property.
FIRST: time of the first execution of the command. Time format: "dd.mm.yyyy hh:mm:ss" or "hh:mm:ss". Default: immediatly
COUNT: the number of repetitions of the command. Default: INDEFINITELY
INTERVAL: The number of seconds to pause between the repeat firing.

Example:
wrapper.timer.simple.RESTART.FIRST=13:30:00
wrapper.timer.simple.RESTART.COUNT=5
wrapper.timer.simple.RESTART.INTERVAL=300

Starts the process at 13:30  then restarts it 5 times at intervals of 5 minutes.

Note that WrapperManger.stop() and WrappedJavaProcess.stop() will stop the application but will not stop the timer.
To stop the timer use WrapperManger.stopTimer() or WrappedJavaProcess.stopTimer()

Note that this is just a "dumb time trigger". It does not consider if the application is startable or if it has been restarted by a filter or by the user.
wrapper.priority priority of the process. The following values are supported: LOW, BELOW_NORMAL, NORMAL, ABOVE_NORMAL, HIGH
Default: NORMAL

Example:
wrapper.priority=BELOW_NORMAL
wrapper.affinity CPU affinity of the process. this is a bit-array representing the cpus.
In case this value is not consistent with the number of processors it is not set.

Example:
wrapper.affinity=1  means CPU 0
wrapper.affinity=2  means CPU 1
wrapper.affinity=3 means CPU 0 and 1
wrapper.java.customProcName Copies java.exe or javaw.exe to the the temp directory. The process can thus be easily found in the task list.
The name will be: java_<customProcName>_nnnn.exe

NOTE: currently only available for windows
wrapper.java.command.minVersion Alternatively to giving the path to the java.exe in the wrapper.java property, YAJSW may search for a given JVM on the computer. The properties in the sequel will indicate which jvm to use.

Minmal required version of the jvm.
Format: x.x.x[_xx]

Example:
wrapper.java.minVersion=1.5.0

NOTE: currently only available for windows
wrapper.java.command.maxVersion Maximal required version of the jvm. If not defined the maximal JVM version found will be used.

Example:
wrapper.java.minVersion=1.4.0

NOTE: currently only available for windows
wrapper.java.command.64bit Indicates if to use a 64 bit jvm
Default: false
wrapper.java.command.jreOnly Indicates to search only for JREs

Example
wrapper.java.jreOnly=true

NOTE: currently only available for windows
wrapper.java.command.preferJre Indicates that JRE are prefered over JDK

NOTE: currently only available for windows
wrapper.java.command.preferJdk Indicates that JDK are prefered over JRE, per default JDKs are prefered.

NOTE: currently only available for windows
wrapper.java.command.jdkOnly Indicates to search only for JDKs

NOTE: currently only available for windows
wrapper.java.command.javaw Use javaw.exe instead of java.exe

NOTE: currently only available for windows
wrapper.jmx If true registers the WrappedProcessMBean to the MBeanServer of the wrapper.
If no MBeanServer has been initialized by the wrapper, eg wrapper was not started with , the wrapper will create one and an RMI acceptor is initialized. Therefore the property -Dcom.sun.management.jmxremote is not required.
Default: false
wrapper.java.jmx If true registers WrapperManagerMBean to the MBeanServer of the java application.
This property is inactive if no MBeanServer has been initialized by the application.
Default: false
NOTE: to initialize an MBeanServer use the JVM option -Dcom.sun.management.jmxremote or check the documentation of your application server.
wrapper.jmx.rmi.port Port for RMI access to the JMX server of the wrapper process.

Default: 1099
wrapper.condition.script
wrapper.condition.script.args
To conditionally control the application a groovy script can be defined.
The process variable can be used to control the process execution.
The args variable is isued to pass the arguments.
Variables defined within the script are
The script is executed cyclically. The cycle is given by the property wrapper.condition.cycle.
The wrapper terminates if the script returns null.
The property defines the name of the script file.
Default: if no condition script is defined no condition check is perormed.

Examples of scripts can be found in the scripts directory.

The following script makes sure that the application is running between 5:00 and 3:00 the next day
wrapper.condition.script=timeCondition.gv
wrapper.condition.script.args=5:00,3:00

The following script makes sure that the application is running while the file "anchor.txt" exists.
And that the application is not running once the file is deleted.
wrapper.condition.script=fileCondition.gv
wrapper.condition.script.args=anchor.txt
wrapper.condition.cycle Execution cycle for the condition script in seconds.
Default: if no cycle is defined the cycle is executed only once, assuming that if required the cycle is implemented within the script

wrapper.condition.cycle=1
wrapper.monitor.<n>
wrapper.monitor.<n>.comparator
wrapper.monitor.<n>.threshold
wrapper.monitor.<n>.action
wrapper.monitor.<n>.script
wrapper.monitor.<n>.script.args
Monitor resources of the application and execute an action or script if threshold is not held.
The following monitors are currently available:
CPU
MEM
THREAD

The following comparators are available:
G :Greater
L: Lower

Default: G

Example: Send an email if  the thread count exceeds 20.
wrapper.monitor.0 = THREAD
wrapper.monitor.0.threshold = 20
wrapper.monitor.0.script = sendMail.gv
wrapper.monitor.0.script.args = toMail@me.com, too many threads in application

wrapper.tray Indicates if a tray icon should be created.
This requires the wrapper to run with JVM 1.6 or higher.
Windows: when installing as service sets wrapper.ntservice.interactive = true
Note: Windows: If combined with wrapper.ntservice.account: the given account must have the according privilges

Default: false

Example
wrapper.tray = true
wrapper.tray.icon Name of the file to be used as icon for the system tray.

Default: If no icon is defined or the defined icon is not found a default icon (console.png) is used.

Example:
wrapper.tray.icon = tomcat.gif
wrapper.app.account User account for running the application. Equivalent to Windows runas or Linux sudo.
wrapper.app.password Optional password for wrapper.app.account
wrapper.ntservice.additional.<n> Additional java options for the wrapper service.
wrapper.ntservice.additional.1=-Xmx5m
wrapper.ntservice.additional.2=-Xms3m
wrapper.ntservice.additional.3=-server
wrapper.filter.missing.trigger-regex.<n>
wrapper.filter.missing.trigger.<n> = <text>,<count>,<period>
wrapper.filter.missing.script.<n>
wrapper.filter.missing.script.<n>.args
wrapper.filter.missing.action.<n>
Some applications may hung although the heartbeat between the wrapper and the application is ok. This happens generally in polling applications which cyclically  log the result of the polling.

This property allows one to specify the expected text, the number of expected occurences and the time period. The trigger is raised if within a time period the number of lines containing the given text is lower than the given count.

Time period is in seconds.
"*" stands for any line for trigger (not for trigger-regex)


Example:

wrapper.filter.missing.trigger.ok  =  *, 1, 10
wrapper.filter.missing.script.ok = sendmail.gv
wrapper.filter.missing.script.ok.args = somebody@help.com,"process restart","process not logging -> restarting"
wrapper.filter.missing.action.ok = RESTART
 
In case the process does not log at least 1 line per 10 seconds an email is sent and the process is restarted.
wrapper.restart.delay.script
wrapper.restart.delay.script.args
Some applications may require a dynamic setting of the restart delay. For example some applications may double the timeout after each restart.
Other applications may want to check resources, such as the availability of network HDD before restarting. Instead of defining a wrapper.restart.delay one may define a script with is executed during restart and which is supposed to return an Integer. If null, or another value is returned the default restart delay is used.

Example:

wrapper.restart.delay.script=scripts/linearRestartDelay.gv
wrapper.restart.delay.script.args=10
 wrapper.app.pre.script Some applications require a script to be executed before the main method of an application is executed. For example, when running as service we may need to set the network printer or the network disk.

Example:

 wrapper.app.pre.script=scripts/mapNetworkDrive.gv

Configuration Properties from tanuki software

Property Name
Comments
wrapper.adviser
wrapper.anchorfile YAJSW implements anchor file with groovy script. Use wrapper.condition.script.
wrapper.anchorfile.umask
wrapper.app.parameter.<n> Application parameters to pass to your application when it is launched. These are the parameters passed to your application's main method.
wrapper.commandfile YAJSW implements command  file with groovy script. Use wrapper.condition.script.
wrapper.console.flush This should already be done by java.
wrapper.console.format Format to use for output to the console. Logging was intentionally kept simple. The format consists of the tokens 'L' for log level, 'P' for prefix, 'D' for thread, 'T' for time, 'Z' for millisecond time, and 'M' for message. If the format contains these values then it will be included in the format. The order of the tokens does not affect the way the log appears, but the 'M' token should usually be placed last as it is the only column without a uniform width. If the property is missing or commented out, then the default value 'PM' will be used. Setting the property to a blank value will cause console output to be disabled.
wrapper.console.loglevel Log level to use for console output. Valid log levels include: NONE for no output, FATAL to only show fatal error messages, ERROR to show all error messages, STATUS to show all state changes, INFO shows all JVM output and informative messages, and DEBUG shows detailed debug information. The default value is INFO.
wrapper.console.title Setting this property allows the Title Bar of the console in which the java application is running to be set.
wrapper.cpu.timeout Timer attributes are not required. We have wrapper.ping.interval. In case of CPU starvation by the application the wrapper will not be pinged.
wrapper.daemonize Whereever possible applications are demonized:
Java applications are daemonized except if wrapper.visible = false
Native images are not deamonized.
wrapper.debug Used to enable further debug information. This requires that logging to a file or the console is enabled.
wrapper.disable_restarts
wrapper.disable_shutdown_hook No shutdown hook is required by YAJSW.
wrapper.filter.action.<n>

The wrapper.filter pair of properties make it possible to filter the output of a JVM and then perform some action whenever a specific trigger string is found. 

Possible actions are RESTART, SHUTDOWN, and NONE. RESTART will stop the current JVM and then restart a new invocation. SHUTDOWN will stop the JVM. NONE is useful because it will prevent any triggers with a higher number from being triggered.

If an action is omitted, it will default to RESTART.

wrapper.filter.trigger.<n>

The wrapper.filter pair of properties make it possible to filter the output of a JVM and then perform some action whenever a specific trigger string is found. The filtering process works by comparing JVM console output against registered triggers until a match is found. At that point the associated action is executed. Only the first matching trigger will be handled for any line of output. 

wrapper.ignore_signals Use wrapper.java.additional.jvm-opts=-Xsr
wrapper.java.additional.<n> Additional Java parameters to pass to Java when it is launched.
wrapper.java.classpath.<n> YAJSW supports wildcard for files as well as folders. However recursive wild cards for folders are currently not supported, but may be supported in future.
For wildcard syntax refer to apache commons.

Examples:

wrapper.java.classpath.1=lib/*/*.jar
wrapper.java.classpath.2=*test*/*.jar
wrapper.java.command The command to use when launching a JVM.
The wrapper checks that the given file exists.

For the wrapper to choose a java command use the wrapper.java.command.* properties.
If wrapper.java.command is set and the file exists, the wrapper.java.command.* are ignored
wrapper.java.command.loglevel
wrapper.java.idfile
wrapper.java.initmemory The initial amount of memory in megabytes that the JVM should allocate. If -Xms is defined using wrapper.java.additional property, then this property is ignored.
wrapper.java.initialmemory.relative is relative to the available total RAM. If this is defined, then wrapper.java.initialmemory is ignored.
wrapper.java.library.path.<n> The library path is used to specify a list of directories in which to look for any native (JNI) libraries used by the application..
Note that YAJSW does not require native libraries for the java application.
wrapper.java.library.path.append_system_path
wrapper.java.mainclass Class to execute when the wrapper starts the application.
The default class is org.rzo.yajsw.WrapperMain. This class will support all required integration methods.
Note that this is not the main class of your java application.
wrapper.java.maxmemory The maximal amount of memory in megabytes that the JVM should allocate. If -Xmx is defined using wrapper.java.additional property, then this property is ignored.
wrapper.java.maxmemory.relative is relative to the available total RAM. If this is defined, then wrapper.java.maxmemory is ignored.
wrapper.java.idfile.umask
wrapper.java.pidfile File to write the java application process ID to. If set, a file containing the pid of the Wrapper process will be written to the specified location when the process is launched. The file will be deleted when the Wrapper process has terminated. This property is not set by default. On process restart the file is updated. The file is not locked and may be deleted by external applications.
wrapper.java.pidfile.umask
wrapper.java.statusfile
wrapper.java.statusfile.umask
wrapper.java.umask
wrapper.jvm_exit.timeout Currently we do not control the jvm exit timeout and the shutdown timeout. We only control the total time required to stop the appliation. If the application is not killed within (wrapper.jvm_exit.timeout  + wrapper.shutdown.timeout) the application is killed by calling TerminateProcess, which immediatly terminates the process.
wrapper.jvm.port JVM port is not required. YAJSW connects from the application to the wrapper, so only one port definition is required. The application port is automatically selected.
wrapper.jvm.port.max
wrapper.jvm.port.min
wrapper.lockfile File to create and lock when process is started. If set, is created and locked when the process is launched. The file will be deleted when the application is idle. This property is not set by default. If the lock file already exists and is locked the process will not start. The lock is maintained during restart of the application. 
wrapper.lockfile.umask
wrapper.logfile Log file to which all output to the console will be logged. If the logfile is not specified, then file logging will be written to a file called "wrapper.log" in the same directory as the Wrapper executable. Providing a blank value will cause file logging to be disabled.

The specified log file name may contain one or both of the tokens; ROLLNUM and YYYYMMDD.

The ROLLNUM token is used when the log file is rolled.

".ROLLNUM" will not be appended by default.

The YYYYMMDD token is required when the wrapper.logfile.rollmode property has a value of DATE. This token will be replaced by the date of the log entries contained in the file.
wrapper.logfile.format Format to use for logging to the log file. Logging was intentionally kept simple. The format consists of the tokens 'L' for log level, 'P' for prefix, 'D' for thread, 'T' for time, 'Z' for millisecond time, and 'M' for message. If the format contains these values then it will be included in the format. The order of the tokens does not affect the way the log appears, but the 'M' token should usually be placed last as it is the only column without a uniform width. If the property is missing or commented out, then the default value 'LPTM' will be used. Setting the property to a blank value will cause file logging to be disabled.
wrapper.logfile.inactivity.timeout
wrapper.logfile.loglevel Log level to use for logging to the log file. Valid log levels include: NONE for no output, FATAL to only show fatal error messages, ERROR to show all error messages, STATUS to show all state changes, INFO shows all JVM output and informative messages, and DEBUG shows detailed debug information. The default value is INFO.
wrapper.logfile.maxfiles When log file rolling is enabled, old log files will be renamed by replacing their ROLLNUM token with an integer or by appending that integer to the end of the file. Larger indices are older log files. The maximum number of rolled log files can be set using this property.
wrapper.logfile.maxsize The wrapper.log file can be set to roll when the file reaches a specified size. The default value of 0 will disable log file rolling. To roll the file, specify a maximum file size in bytes. The size can be abbreviated with the suffixes 'k' for kilobytes, or 'm' for megabytes. For example, '10m' sets the log file to be rolled when it reaches a size of 10 megabytes.
wrapper.logfile.rollmode

Controls the roll mode of the log file. Possible values include:

  • JVM - The log file will be rolled on Wrapper startup as with the WRAPPER mode. But it will also be rolled just before any restarted JVMs are launced. The log files will not have a maximum size and will continue to grow until the Wrapper or a JVM is restarted.

  • DATE - As each log entry is logged to a file, its timestamp is compared with a YYYYMMDD formatted token in the current log file. Whenever this date changes a new log file will be opened. This has the benefit of grouping all log entries for a given day in a specific file. A file will not be created on days which do not have any log output.

wrapper.logfile.umask
wrapper.max_failed_invocations Maximum number of times that the Wrapper will attempt to restart the JVM if each attempted invocation exits abnormally or is restarted shortly after having being launched. Must be at least 1. Defaults to 5 invocations.
wrapper.monitor_thread_count
wrapper.native_library YAJSW does not require a native library for the java application.
wrapper.ntservice.account User name to be used by the windows service.
On windows the format should be: <domain>\<user>
wrapper.ntservice.console
wrapper.ntservice.dependency.<n> Names of any other Services or groups which must be running before this service can be started. Stopping any of the listed services, or all members of a specified group, will also stop this service. Because both services and groups share the same name space, group names must be prefixed with the '+' character.
wrapper.ntservice.description Description of the NT service when installed.
wrapper.ntservice.displayname Display name of the NT service when installed.
wrapper.ntservice.hide_console
wrapper.ntservice.interactive Note: Windows: If combined with wrapper.ntservice.account: the given account must have the according privilges
Please note potential security risks associated with this.
wrapper.ntservice.load_order_group
wrapper.ntservice.name Name of the NT service when installed.
wrapper.ntservice.password password for user specified by wrapper.ntservice.account.
wrapper.ntservice.password.prompt
wrapper.ntservice.password.prompt.mask
wrapper.ntservice.pausable
wrapper.ntservice.pausable.stop_jvm
wrapper.ntservice.process_priority
wrapper.ntservice.starttype Mode in which the service is installed. AUTO_START or DEMAND_START
Default: AUTO_START
wrapper.on_exit.<n>

It may be desirable to restart the application in the event that it exits with certain exit codes. This set of properties makes this possible.

It possible to specify an action to take for any exit code by making use of the wrapper.on_exit.default property and setting it to either SHUTDOWN or RESTART. The default on_exit property defaults to SHUTDOWN.

wrapper.pidfile File to write the wrapper  process ID to. If set, a file containing the pid of the wrapper process will be written to the specified location when the process is launched. The file will be deleted when the application process has terminated. This property is not set by default. The file is not locked and may be deleted by external applications.
wrapper.pidfile.umask
wrapper.ping.interval Number of seconds between java application ping requests to the wrapper. Defaults to 5 seconds.
wrapper.ping.interval.logged
wrapper.ping.timeout Number of seconds the wrapper waits for a ping message from the java application. The application is considered for restart if no ping message is received within the give timeout. This value should be greater or equal to wrapper.ping.interval. Default is 30 seconds.
wrapper.port The Wrapper uses a socket to communicate with the java or groovy application. It waits for the application to connect. Only connections from localhost are accepted. Only a single connection which has been authenticated is accepted. All other connections are rejected. If the application has not authenticated itsself within a timeout, the wrapper will restart it.

Generally the wrapper will search for a free port. In some cases you may need to assign a specific port or a range of ports.

This property allows the configuration of a specific port.

NOTE: native applications are currently not wrapped by java. Therefore the wrapper (controller) only monitors that the application is running. It does not monitor hangging of the application and therefore does not require a port.
wrapper.port.max The wrapper searches a free port by starting at wrapper.port.min and terminating at port wrapper.port.max.
If this property is not defined the wrapper will iterate through all ports, starting at wrapper.port.min.

Per default no max port is defined.
wrapper.port.min This property defines the first port to use while searching for a free port.

Default min port is: 15003
wrapper.registry.java_home
wrapper.request_thread_dump_on_failed_jvm_exit
wrapper.restart.delay Controls the number of seconds to pause between a JVM exiting for any reason, and a new JVM being launched. Defaults to 5 seconds.
wrapper.restart.reload_configuration Controls whether or not the Wrapper configuration file will be reloaded in the event of a JVM restart. Defaults to FALSE.
NOTE: currently only the configuration file is reloaded. Environement or System properties changes are not.
NOTE: This property may be changed when reloading the configuration.
wrapper.shutdown.timeout see wrapper.jvm_exit.timeout
wrapper.signal.mode.hup
wrapper.signal.mode.usr1
wrapper.signal.mode.usr2
wrapper.single_invocation
wrapper.startup.delay Number of seconds to pause between the Wrapper being launched and the first JVM being launched.

Default: 0
wrapper.startup.timeout Number of seconds to allow between the time that the Wrapper asks the JVM to shutdown and the time that the JVM shuts down.. Defaults to 30 seconds. The JVM is killed if it does not shut down within the given timeout.
wrapper.statusfile
wrapper.statusfile.umask
wrapper.successful_invocation_time Specifies the amount of time that an application must remain running before it will be considered to have been a successful invocation. This property's use is described in the description of the wrapper.max_failed_invocations property. Defaults to 60 seconds.
wrapper.syslog.facility
wrapper.syslog.ident
wrapper.syslog.loglevel
wrapper.thread_count_delay
wrapper.timer_fast_threshold Timer attributes are not required. We have wrapper.ping.interval. In case of CPU starvation by the application the wrapper will not be pinged.
wrapper.timer_slow_threshold Timer attributes are not required. We have wrapper.ping.interval. In case of CPU starvation by the application the wrapper will not be pinged.
wrapper.umask
wrapper.use_system_time Timer attributes are not required. We have wrapper.ping.interval. In case of CPU starvation by the application the wrapper will not be pinged.
wrapper.working.dir Working directory for the java application.