YAJSW Configuration Properties

1. Introduction
   1. 1. 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.relativize_classpath | WrappedJavaProcess.java unwraps wildcarded classpath entries into full canonical paths of each of the files found. On large programs, this causes the wrapper to fail on Windows since the command line then exceeds 32768 characters. By relativizing the classpaths wrt the working directory, this problem is mitigated. If wrapper.java.app.relativize_classpath is set to true the classpath in the command line will be relativized. Example: wrapper.java.app.relativize_classpath=true Default: false
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.java.app.module-path.<n> | jdk 9+ yajsw 13+ equivalent to --module-path
wrapper.java.app.module | jdk 9+ yajsw 13+ equivalent to -module note: -m com.module/mainclass is configured as follows: wrapper.java.app.module = com.module wrapper.java.app.mainclass = mainclass
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/dis`t` 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.ping.check_ack | There are cases where the tcp/ip communication is interrupted by the client socket is not closed by the OS. The application in the case sends a ping without a tcp/ip error. In this case, check that the application receives an application level ack when a ping is transmitted. Default: false Example: wrapper.ping.check_ack=true
wrapper.delay_shutdown | On shutdown of the wrapper we may need to delay the wrapper termination for some script to terminate. This property indicates how many seconds the termination of the process will be delayed. Note: If this is longer than the value set on OS level for shutting down a service the OS will terminate the wrapper and log an error. Default: 0 Example: wrapper.delay_shutdown=40
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.