Google

Locations of visitors to this page

Hosted by:
SourceForge

Cascading Configuration Files
Cascading Configuration Files
Configuration Property Overview
Cascading Configuration Files

Starting with version 3.0.0, it is possible to specify include files within a configuration file. This is useful where there is a need to override default values without modifying the main configuration file.

Include files are specified by placing a line in the configuration file with the following syntax:

#include ../conf/wrapper2.conf

If the specified file can not be located for any reason then it is ignored. This makes it easy to specify a series of optional include files which users may or may not create.

The location of the include definition in a file is important. Any properties defined before the include can be overridden where as properties set after the include file will override any settings in the include files. This rule applies to the contents of include files as well.

If relative paths to the include files are specified, be aware that all paths must be relative to the location of the Wrapper working directory. By default, this is the location of the Wrapper.exe on Windows, or the script used to launch the Wrapper on UNIX. The working directory can be changed using the wrapper.working.dir property, but this does not take effect until after the full configuration file has been loaded. This means that relative include file references will always be relative to the original working directory of the Wrapper.

Include files can be nested up to 10 levels deep.

Include files are designed to be optional so the Wrapper will silently skip the include file if it can not be found. This can make debugging problems involving include files frustrating. To help with this, it is possible to enable debug messages about include files using the following declaration before any #include file references. Be aware that this debug output will done before your configured logging properties have been processed. The output will show up on the console as well as in the default wrapper.log file, which will be located in the same directory as the wrapper binary. If the wrapper is being run as a windows service then the default wrapper.log will show up in the Windows system32 directory.

#include.debug


User Comments

If you notice something that is incorrect, missing, or simply feel that some part of this page could be explained better, feel free to log in and add a comment. You will need to register before you can log on.

Email:
Password:
by Leif Mortenson (2007/12/06 23:14:56 JST from 192.168.11.145)
Gravatar

Include files are intentionally always relative to the original working directory which is all normal cases the location of the wrapper binary. This true for the initial load of the Wrapper.conf as well as any reloads.

All other paths in the configuration file will be relative to the value of wrapper.working.dir.

I have added a new feature to enable debugging of includes in version 3.3.0. That should help with problems like this.

Cheers,
Leif

by Juergen Hermann (2007/12/06 22:55:00 JST from 212.227.35.93)
Gravatar

Includes do NOT honor the wrapper.working.dir property, so you should use absolute paths.

last modified: