YAJSW Configuration Properties

  1. Introduction
        1. General Notes
        2. Accessing Environment Properties
        3. Includes
        4. Conditional Includes
        5. Groovy Expressions
        6. Multiple Lines
        7. Lists and arrays
        8. Multiple Value Properties
        9. Classpath Wildcards
        10. New  Configuration Properties
        11. New Optional Configuration Properties
        12. Configuration Properties from tanuki software

Introduction

In order to wrap an application you will either need to create a configuration file or specify the configuration properties as command line attributes of the wrapper exe.
It is recommended to create a configuration file and store it in the <yajsw>/conf folder.

You can create a configuration file for a running application by using the configuration generator.

In the following we describe the configuration properties.

NOTE: this description applies only for configuration properties and configuration files. It does not apply for batch scripts such as <yajsw>/bat/setenv.bat or <yajsw>/bat/setenv.sh

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

 NOTE:
${abc.efg} is similar to ${abc.getefg()} therefore

do not use "." in environment or configuration variables.

instead use : ${abc_efg}

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
do not use:

wrapper.java.additional.2=-Xdebug -Xrunjdwp:transport=dt_socket\,server=y\,suspend=y\,address=1044

instead:

wrapper.java.additional.2.1=-Xdebug
wrapper.java.additional.2.2=-Xrunjdwp:transport=dt_socket\,server=y\,suspend=y\,address=1044

use one java option or main method argument per configuration property.


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

NOTE: Windows: environment variables are converted to lower case. Therefore event if  you use PATH on your computer you have too call ${path} in the configuration file.

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


Classpath Wildcards

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.
Note that in YAJSW wildcards are used differently then in java.

In java lib/* denotes all .jar files in the lib folder. In YAJSW this will denote all files in the lib folder. To denote the jar files in a folder please use lib/*.jar

Examples:
wrapper.java.classpath.lib=lib/*/*.jar
wrapper.java.classpath.test=*test*/*.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
- CHANGED since beta 10.3		 For Posix OS: Directory in which to create K... and S... links
Default: <wrapper.daemon.dir>/rcX.d

Example 1: For Ubuntu:

wrapper.daemon.run_level_dir=/etc/rcX.d

will create the links

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

depending on the settings of the property wrapper.daemon.update_rc
wrapper.daemon.update_rc For Posix OS: This property allows setting the runlevels and priorities for automatic startup and stop of the daemon with a similar syntax as the update_rc.d command.

Per default creates links for stop runevels 0, 1,  6 and start runlevels 2, 3, 4, 5  with priority 20.

NOTE the difference: no closing "." is required.

NOTE: uninstall the daemon using <yajsw>/bat/uninstallDaemon.sh before changing the property wrapper.daemon.run_level_dir property  or wrapper.daemon.update_rc. If you change any of these properties while the daemon is installed or running, you will not be able to start, stop, install or uninstall the daemon.

  • Custom Priorities:
wrapper.update_rc = 91

will create links at default start and stop runlevels with priority 91
  • Different Priorities for start and stop:
wrapper.update_rc = 20 80

will create links at default start and stop runlevels with start priority 20 and stop priority 80
  • Custom Run Levels:
wrapper.update_rc = start 20 2 3 4 . start 30 5 . stop 80 0 1 6

will create start links at runlevels 2, 3, 4 with priority 20 at runlevel 5 with priority 30 and stop links at runlevels 0, 1, 6 with priority 80

In this case the following links are created:

/etc/init.d/rc0.d/K80<service name>
/etc/init.d/rc1.d/K80<service name>
/etc/init.d/rc6.d/K80<service name>
/etc/init.d/rc2.d/S20<service name>
/etc/init.d/rc3.d/S20<service name>
/etc/init.d/rc4.d/S20<service name>
/etc/init.d/rc5.d/S30<service name>
wrapper.daemon.k_order.<n>
-DEPRECATED since beta-10.3		 For Posix OS: the link K...  will be named: K<wrapper.daemon.k_order><wrapper.ntservice.name>
Default: 99
wrapper.daemon.s_order.<n>
- DEPRECATED since beta-10.3		 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.ntservice.autoreport.startup For Windows: if set to false the wrapper will not report service startup to the windows service manager. Instead the application is expected to call WrapperJVMMain.WRAPPER_MANAGER.reportServiceStartup() thus notifying the windows service manager, that the application is up and ready. The wrapper will report to the windows service manager as startup time the value of the property wrapper.startup.timeout. If the application does not invoke reportServiceStartup() within this timeout the service is stopped.

Default: true. In this case the wrapper will not wait for the application to startup and will notify the service manager as soon as possible.
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 started only 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
wrapper.app.env.<variable> Defines an environment variable which is set when executing the application.

Example:

wrapper.app.env.path = /path-to-some-dll;${path}
wrapper.fork_hack On Linux/OSX/Unix calling fork/exec from within java/jna may not allways work due to multithreading.
Activating the "fork hack" will start the sub-process by using standard java Runtime.exec instead.
Set this property to true, if you are having issues starting your application. Before that make sure that your issues are not caused by wrong configuration.

Default: false

Example:

wrapper.fork_hack = true
wrapper.save_interpolated Per default, when installing a service, the yajsw "saves" the value of interpolations, eg configuration values accessed using ${xxx}. It thus makes sure that the service is started with the same settings as when it was installed. There are cases where this is not desired and interpolations should be reevaluated at service start. For this usecase set this property to false

Default: true

Example:

wrapper.save_interpolated = false
wrapper.ntservice.failure_actions.reset_period
wrapper.ntservice.failure_actions.reboot_msg
wrapper.ntservice.failure_actions.command
wrapper.ntservice.failure_actions.actions
wrapper.ntservice.failure_actions.actions_delay		 Properties for setting windows service recovery.
For more details refer to the windows documentation
These properties do not refer to the wrapped application but to the wrapper process.

NOTE: When setting this property you will have to consider the setting of the wrapper.control property. If this property is not set to TIGHT restarting of the service (wrapper process) may result in multiple application processes running.

actions is a comma separated list which can take the following string values:
  • NONE
  • REBOOT
  • RESTART
  • COMMAND
default: no actions
reset_period: default is 0, set to -1 for INFINITE

actions_delay: is a comma separated list of delays in milliseconds. Default is 0. If the list is shorter than the actions list, the last delay in the list is used for the rest of the actions.

Example:

wrapper.ntservice.failure_actions.actions = RESTART
wrapper.ntservice.failure_actions.actions_delay=60000

This will restart the wrapper every time it crashes with a delay of 1 minute.

wrapper.ntservice.failure_actions.actions = RESTART, NONE
wrapper.ntservice.failure_actions.actions_delay=60000

This will restart the wrapper only once.

NOTE: The winodws services gui cannot display all settings of these properties. To check that failure actions have been set you may check the registry HKEY_LOCAL_MACHINE\SYSTEM\Services\<service name>\FailureActions.

NOTE: setting REBOOT requires the according user rights.

NOTE: similar functionality can be implemented using groovy scripts resulting in platform independent configuration.
wrapper.script.reload Indicates to the wrapper to check if scripts' files' last changed time should be checked before each execution. If the file has changed it will be reloaded.

Default: false
wrapper.script.encoding
wrapper.log.encoding
wrapper.conf.encoding		 Set the encoding of  files.

Default: the java default encoding .

Example:

wrapper.log.encoding = UTF-8
wrapper.console.pipestreams Per default stdout, stderr and stdin are piped to null whereas the java System.in, System.out and System.err are T-ed to the wrapper.
This has the advantage, that the wrapper and the application can run independently (currently only on windows) . However errors from the java launcher errors are not logged in the wrapper.
Setting this property to true will stream the std streams to the wrapper instead of T-ing.

Default: java applications: false, native applications: true

Example:

wrapper.console.pipestreams = true
wrapper.config.script.<n> The configuration can be extended to include user defined groovy scripts. <n> is the binding which is used to invoke the script within the configuration.

Example:

wrapper.config.script.decryptor = scripts/decrypt.gv

invocation:

wrapper.ntservice.password =${decryptor.invoke('decrypt'\, 'aplasdfjlk')}
wrapper.cleanup_tmp Per default at startup (WrappedProcess.init(), startInternal()) the wrapper will delete all err_, in_, out_ files from the tmp folder.
To disable, set this boolean property to false.

Default : true

Example:

wrapper.cleanup_tmp = false
wrapper.tray.spawn_process Per default runConsole will spawn the system tray icon process, if wrapper.tray is set.
To disable, set this property to false.

Default: true

Example:

wrapper.tray.spawn_process = false
wrapper.logfile.maxdays  maximal number of logfile days to keep if wrapper.logfile.rollmode is set to DATE. wrapper.logfile.maxfiles is the maximal number of files  to keep per day. Thus a burst in logging, for example due to a bug, will not affect previous days.

Default: -1, eg keep all days.
wrapper.ntservice.reduce_signals In case the application is using Signal.handle(new Signal(..)) the wrapped service should not set the java option -Xrs.
In this case you should set this property to false.

Default: true

Example:

wrapper.ntservice.reduce_signals = true
wrapper.console.use_interpolated In case java options are used by the wrapper, these are per default, if they are used in the configuration then they are added to the java options of the wrapped application.
In cases, where this is not desired, set this property to false.

Default: false

Example:

wrapper.console.use_interpolated = false
wrapper.app.status.log.lines Maximal number of lines read from the wrapped application which are logged by the wrapper in case the log level is set to STATUS

Default: 100

Example:

wrapper.app.status.log.lines = 40
wrapper....script.<n>.maxConcInvoc Filter triggers execute scripts in a separate thread. In order to avoid overusage of threads when a filter trigger is executing a script a mximal number of concurrent executions of the script is set. If more than maxConcInvoc scripts are invoked while a script is  executing subsequent invocations are ignored.

Default: 5
wrapper.debug.level Control how talkative yajsw logfile is.

0 : only pid of application process, and stop of application
1 : debug information on applicaiton start/stop
2 : some more information
3:  full debug information

Note: check the source for details. If you think that another assignment of messages to levels makes more sense pls post.

This property is read only if wrapper.debug is set to true

Default: 3

Example:

wrapper.debug = true
wrapper.debug.level = 1
 
wrapper.filter.debug.default To avoid major changes to existing installations some users require a property to change the default settings of the property wrapper.filter.debug. check source for more details.
wrapper.wrapperJar
wrapper.appJar		 When embedding yajsw in another application one may want to be able to update the jars used by the application and by the wrapper separately. These properties are set if the wrapped applicaiton should use a different jar file. They point to the full path of the jar file.
wrapper.logfile.desc Per default, when log files are rotated all log files have to be renamed: The most recent log file has the extension 1. This is not desirable in cases where the log files are synchronized to the cloud, because with each rotation all files have to be synchronized.

Setting this property to true will rename only the newest file. Thus the most recent log file (except the current) will have the highest extension whereas the oldest one will have the lowest.

Default: false

Example:

wrapper.logfile.desc = true

will result in the following log files sorted by last modified:

wrapper.log
wrapper.log.3
wrapper.log.2
wrapper.log.1

wrapper.logfile.desc = false

will result in the following log files sorted by last modified:

wrapper.log
wrapper.log.1
wrapper.log.2
wrapper.log.3
wrapper.posix_spawn Spawning a child process using fork/exec has resulted in some issues, when invoked from java.
As result of this the property wrapper.fork_hack was introduced, which is however also not perfect.

The best option seems to be posix_spawn.

Default: false (for backwards compatibility)

Please test this option and post your feedback.

In future this option will be set to true by default and will be used per default on all posix systems.
wrapper.posix_vfork This property is used only if wrapper.posix_spawn is true.

If set to true, posix_spawn is invoked with the attribute property vfork.
For some more information see here.

Default: false

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.<n>.<state>
wrapper.script.<n>.<state>.args
wrapper.script.<n>.<state>.timeout		 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"

timeout is the maximal time, in seconds,  the wrapper waits for the script to terminate. Default is 30 seconds.

If the script does not terminate within the given duration, the wrapper will try to interrupt it and will continue its operation. Note that there is no guaranty that the script will be interupted.

Note: state change scripts are not excuted in a separate thread. They may therefore delay the wrapper execution.
Note: for backward compatibility: wrapper.script.<state> is equivalent to setting <n> to "". For the same state execution order is the alpha numeric order of <n>
wrapper.filter.script.<n>
wrapper.filter.script.<n>.args
wrapper.filter.script.<n>.timeout		 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

If the script does not terminate within the given duration, the wrapper will try to interrupt it and will continue its operation. Note that there is no guaranty that the script will be interupted.

Note that filter scripts are executed in a separate thread, so us not to delay the processing reading from the application console.
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.cron.RESTART=* * 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 To easily find applications in the task list, the java exe may be copied to a file with a different name.

This property indicates to yajsw to copy java.exe or javaw.exe to a file with a given name. If the property (after interpolation) specifies a full path to a file with existing parent path, the given path is used and the file is not marked for deletion on exit. Otherwise a temporary file (call to File.createTempFile())   named java_<customProcName>_nnnn.exe is created.

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.jmx.rmi.user
wrapper.jmx.rmi.password		 Sets the credentials for JMX access, thus avoiding the handling and creation of jmx rmi credentials file. Password is per default the empty string.
The url for accessing the wrapper is:

service:jmx:rmi:///jndi/rmi://localhost:<wrapper.jmx.rmi.port>/server

NOTE: per default no user/password is set. If user is set password is optional.
NOTE: System Tray Icon will read the credentials from the configuration file.
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 used to pass the arguments.
For bindings defined within the script see the documentation.
The script is executed cyclically. The cycle is given by the property wrapper.condition.cycle, which is in seconds.file:///Z:/dev/yajsw/doc/index.html
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.java.monitor.deadlock
wrapper.java.monitor.deadlock.interval		 Monitors deadlocks from within the wrapped application. In case a deadlock is detected the message

wrapper.java.monitor.deadlock: DEADLOCK IN THREADS:

and a stacktrace of the according threads is printed to the log file.

By defining a trigger on this output one may define the action or script to execute in the case that a deadlock is detected.

wrapper.java.monitor.deadlock.interval can be used to set the interval for the check cycle in seconds. Default is 30 seconds.

Example: Turn monitoring on and display a system tray message when a deadlock is detected:

wrapper.java.monitor.deadlock = true
wrapper.filter.trigger.deadlock.tray = wrapper.java.monitor.deadlock: DEADLOCK IN THREADS:
wrapper.filter.script.deadlock.tray = scripts/trayMessage.gv
wrapper.filter.script.deadlock.tray.arg s= Deadlock Detected
wrapper.java.monitor.heap
wrapper.java.monitor.heap.threshold.percent
wrapper.java.monitor.heap.interval
wrapper.java.monitor.heap.restart		 Monitor the heap size from within the wrapped application. In case the heap exceeds the given threshold the message

wrapper.java.monitor.heap: HEAP SIZE

is printed to the log file.

By defining a trigger on this output one may define the action or script to execute in case a threshold violation is detected.

wrapper.java.monitor.heap.threshold.percent can be used to define the threshold in precent ( usedHeap / maxHeap * 100 ). Default value is 95.

wrapper.java.monitor.heap.interval can be used to set the interval for the check cycle in seconds. Default is 30 seconds.

If wrapper.java.monitor.heap.restart is set then used heap is sent from the application to the wrapper within the ping message.
If wrapper.java.monitor.heap.threshold.percent is also set the application will be restarted by the wrapper if  the used heap exceeds the given threshold.


Example: Turn on monitoring and display a system tray message when the heap size exceeds the default threshold:

wrapper.java.monitor.heap = true
wrapper.filter.trigger.heap.tray = wrapper.java.monitor.heap: HEAP SIZE
wrapper.filter.script.heap.tray = scripts/trayMessage.gv
wrapper.filter.script.heap.tray.args = Heap Issue Detected

Example: Restart the application if the used heap exceeds 99% of maximal heap:

wrapper.java.monitor.heap.restart = true
wrapper.java.monitor.heap.threshold.percent=99
wrapper.java.monitor.gc
wrapper.java.monitor.gc.interval
wrapper.java.monitor.gc.threshold
wrapper.java.monitor.gc.restart		 This is similar to setting the "-verbose:gc"  java option.
The difference is that the output is written to System.err and you set a pattern for the output.

wrapper.java.monitor.gc  is a java MessageFormat pattern which is formatted with the following arguments: Used Heap, Minor GC Duration, Full GC Duration

wrapper.java.monitor.gc.interval can be used to set the interval for the check cycle in seconds. Default is 30 seconds.

If wrapper.java.monitor.gc.restart is set then used heap and full gc duration are sent from the application to the wrapper within the ping message.
If wrapper.java.monitor.gc.threshold is also set the application will be restarted by the wrapper if  the full gc duration (millis)  exceeds the given threshold.

Example: Turn on monitoring and print the data in CSV format:

wrapper.java.monitor.gc=MYGC: {0\,number\,integer}\, {1\,number\,integer}\, {2\,number\,integer}

Example: Restart the application if the jvm executes full gc for "too long":

wrapper.java.monitor.gc.restart = true
wrapper.java.monitor.gc.threshold=2500
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.tray.commands A list indicating which commands are to be displayed in the system tray icon popup. Following values are possible:

start
stop
restart
console
response
exitWrapper
startService
exitTray

Default: all menue points are displayed.

Example:
wrapper.tray.commands = startService, exitWrapper

Note:  this is a list ->  "," should not be escaped.
wrapper.ntservice.autoreport.waitready Boolean value indicating if the tray icon status should be set to waiting until the application calls the method WrapperJVMMain.WRAPPER_MANAGER.reportServiceStartup().

Default: false

Example:

wrapper.ntservice.autoreport.waitready = true
wrapper.tray.dialog Boolean value indicating if the user should be displayed a dialog before stop, restart, exitWrapper, exitTray commands are executed.

Default: true

Example:

wrapper.tray.dialog = false
wrapper.tray.text.dialog_exit_tray, wrapper.tray.text.dialog_stop, wrapper.tray.text.dialog_restart, wrapper.tray.text.dialog_exit_wrapper Texts for the dialogs displayed to the user when calling stop, restart, exitWrapper, exitTray commands.

Default: if the property is not defined a default text is displayed. See source code for more information.
wrapper.tray.look_and_feel Set the look and feel for the system tray icon menue and console.
This property expects the name of a L&F class.
If the given class cannot be loaded the default L&F is used.

Default: default L&F

Example:

wrapper.tray.look_and_feel = com.sun.java.swing.plaf.windows.WindowsLookAndFeel
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.ntservice.java.command Enables to set the java command for the service wrapper.
Default: use the same java command as for the application.

NOTE: when running as console the wrapper java command is set in the batch file setenv.
wrapper.ntservice.java.customProcName To easily find applications in the task list, the java exe may be copied to a file with a different name.
The copied file is used with the wrapper process when run as service.

This property indicates to yajsw to copy java.exe or javaw.exe to a file with a given name. If the property (after interpolation) specifies a full path to a file with existing parent path, the given path is used. Otherwise a temporary file
   File.createTempFile( java_<customProcName>_nnnn.exe))  
is created. The file is not marked for deletion.

Copying of file is done during install of the service.

If you use a temporary file, you should make sure that the file is not deleted on reboot. Otherwise the service may not be restarted.

Default: java exe is not copied.

NOTE: currently only available for windows
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>
wrapper.filter.missing.autostop.<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)

The boolean property wrapper.filter.missing.autostop.<n> indicates if the monitoring  is stopped after the first trigger. Default is true.

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
wrapper.java.debug.port To debug the application one may set the wrapper.java.additional properties to -Xdebug and -Xrunjdwp:transport=dt_socket\,server=y\,suspend=y\,address=1044. However when debuging the wrapper may run into time outs thus restarting the application. To avoid this one may instead set the attributewrapper.java.debug.port. This will add the above jvm options and will set the wrapper timeouts to a maximum.

Example:

wrapper.java.debug.port = 1044

Will result in :

java -Xdebug  -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=1044 ...
wrapper.app.pre_main.script Some applications require a script to be executed before the main method is invoked but after the wrapper heart beat is initiated. The script is invoked with the application args.
wrapper.console.minimized Boolean (true, false) indicating if the console of the application should be visible started minimized.
Default: false

NOTE:
This property takes effect only if  wrapper.console.visible is true.
This property is only effective on windows.
wrapper.ntservice.logon_active_session
wrapper.ntservice.desktop		 Handle Windows Vista (and higher) Session 0 service restriction.
see here
wrapper.restart.reload_cache If this property is set to true in conjunction with wrapper.restart.reload_configuration and network launching:
on each restart he wrapper will reload the configuration and update the cache.

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.

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.

YAJSW extension: to control end of line characters other than java default append "\r\n" or "\n" or "\n" to the end. Default is System.getProperty("line.separator")

Example:

wrapper.logfile.format = LPTM\r\n
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 or (for windows vista and higher only) DELAYED_AUTO_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.

STOP: stop the application but not the wrapper

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 application to start and the time that the wrapped application connects to the wrapper and sends the correct key. Defaults to 30 seconds. The JVM is killed if it does not start 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.