Compatibility :	3.5.0
Editions :
Platforms :

This property specifies the output language of the Wrapper.

On Windows, the value must be one of the installed languages. Please refer to the list of supported languages on Microsoft website. The short notation (language tag) is preferred and can be written with a '_' instead of a '-' for cross-compatibility with Unix systems.

On UNIX based systems, the value has to be the valid part 'language[_territory]' of an installed locale.

In order to get the installed and available locales on UNIX systems, please run "locale -a".

locale -a
C
de_AT.utf8
de_BE.utf8
de_CH.utf8
de_DE.utf8
de_DE@euro
de_DE.iso885915@euro
de_LI.utf8
de_LU.utf8
en_AG
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_NG
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZW.utf8
ja_JP.eucjp
ja_JP.shiftjis
ja_JP.utf8
POSIX

You only need to set the 'language[_territory]' part for this property. The encoding will be set in the wrapper.lang.windows.encoding or wrapper.lang.unix.encoding properties.

wrapper.lang=ja_JP

Starting with Wrapper version 3.5.28, the wrapper.lang property can also be set with the following values:

• DESKTOP for the UI language.
• SYSTEM for the system language (commonly referred to as 'Language for non-unicode programs').

On Windows, the default value is DESKTOP. Prior to version 3.5.28, the language was resolved using the language identifier of the Region Format settings.

On UNIX based operating systems, both 'DESKTOP' and 'SYSTEM' are considered as default values and resolved as the language of the current session.

Since version 3.5.31, the Wrapper will try using a different letter case (for example 'JA_JP' instead of 'ja_JP') if no exact match could be found when searching among the languages installed on the system. This is done to improve portability as lowercase or uppercase characters may be used for a same language depending on the platform. When running on a single server, it is however recommended to set the value exactly as returned by the 'locale' command.

It is also possible to specify a modifier (e.g., @euro) after the language. If wrapper.lang.encoding is also set, the modifier will be automatically added after the encoding when setting the locale. Usually it should not be needed to add the modifier because the Wrapper also searches among locales ignoring the modifiers if no exact match could be found.

Compatibility :	3.5.0 (Deprecated as of 3.5.35)
Editions :
Platforms :

This property specifies the encoding of the Wrapper process which is used to read the JVM output and to write log outputs. The selected encoding has to be installed on the OS in order to make use of it. When the Wrapper can't set the encoding, it falls back using the encoding of the environment on which it was launched.

Compatibility :	3.5.35
Editions :
Platforms :

This set of properties was introduced in version 3.5.35 to configure the encoding of the Wrapper process (used to read the JVM output and to write log outputs) in a cross-platform way.

While Unix systems often use the same syntax for encodings, Windows uses code pages instead of names. If the Wrapper is aimed to run on both platforms, you may use both wrapper.lang.unix.encoding and wrapper.lang.windows.encoding in your configuration file to set the encoding for each platform.

Unix systems often use the same syntax for encodings. Sometimes the case or punctuation may differ (e.g. 'UTF-8' vs 'utf8'), but the Wrapper will resolve such cases automatically if no exact match could be found. However, some OS use platform-specific names and it can be useful to target these encodings with dedicated properties. This is possible using any of the platform names listed below. If the property for a Unix platform isn't specified, the default value will be the value of wrapper.lang.unix.encoding.

The supported values for <platform> are:

• windows (see wrapper.lang.windows.encoding)

• unix (see wrapper.lang.unix.encoding)

• aix

• freebsd

• hpux

• linux

• macosx

• solaris

• zos

wrapper.lang=ja_JP
wrapper.lang.windows.encoding=20932
wrapper.lang.unix.encoding=eucJP
wrapper.lang.aix.encoding=IBM-eucJP

wrapper.lang.windows.encoding

Compatibility : 3.5.35 Editions : Platforms : This property was added in version 3.5.35 to bring support of encodings on Windows. The default value is 'ANSI' which refers to the default OS ANSI code page. This is the same value that the JVM uses by default. Setting this property to another value will have two effects: - First, the Wrapper will pass the encoding to the JVM by adding the file.encoding system property to the list of JVM arguments. This ensures that the JVM and Wrapper respectively write and read using the same encoding. - Secondly, the locale of the Wrapper process will be updated so that all Wrapper outputs can be written to the log file using the same encoding. The value of this property can be set to one of the Windows Code Pages Identifiers. Note however that the Wrapper will restrict some values when the code page can't be used to write to the console (see the warning at the bottom of this section), or when the code page is known to be incompatible with the configured language. As of 3.5.35, the compatibility is only checked for the languages provided with the Wrapper (i.e. English, German and Japanese): - English is compatible with all code pages because it contains only ANSI characters. - German supports the following code pages: 437, 850, 1141, 1250, 1252, 20106, 20273, 28591, 28592, 65000, and 65001 (UTF-8) - Japanese supports the following code pages: 932, 10001, 20290, 20932, 21027, 50220, 50221, 50222, 50930, 50931, 50939, 51932, 65000 and 65001 (UTF-8) WARNING Unlike Unix systems, Windows doesn't check compatibility between a code page and language when setting a locale. This means that a language (other than the above listed ones) associated with a wrong code page may result in garbled outputs, without means for the Wrapper to know about it. By default, the Wrapper localization is resolved using the language of the user interface which may vary depending on the machine. To ensure a correct encoding through the different platforms, wrapper.lang.windows.encoding must be set to 'ANSI' (or left to default), 'OEM' or 'UTF-8' if wrapper.lang is set to 'DESKTOP' or 'SYSTEM'. Example: (set the encoding to eucJP) wrapper.lang=ja_JP wrapper.lang.windows.encoding=20932 It is also possible to specify 'UTF-8', 'ANSI' or 'OEM'. The last two stand for the OS ANSI code page and OS OEM code page. Example: (set the encoding to UTF-8) wrapper.lang=de_DE wrapper.lang.windows.encoding=UTF-8 Note that some encodings like UTF-8 contain characters coded in more than 2 bytes. The locale of the Wrapper process can't be set with a DBCS code page, but the Wrapper operates internally in Unicode and will apply a conversion to write the log output in the correct encoding. WARNING The Wrapper can use two different modes when logging its output to the console. These modes can be controlled with the wrapper.console.direct property. When set to TRUE, which is the default, the console operates in Unicode and any conversion from the value of wrapper.lang.windows.encoding will be supported. However, you should make sure that the font of the console supports the characters of the language. The font can be changed from the 'Properties' windows of the console. When wrapper.console.direct is set to FALSE, the Wrapper will make use of stdout and stderr, which requires all outputs to be written in the console code page so that they can be decoded and displayed correctly at the opposite side of the streams. In this mode, any value of wrapper.lang.windows.encoding that is not compatible with the console code page will be rejected. NOTE In addition to set the encoding of the Wrapper output, wrapper.lang.windows.encoding is also used when reading the JVM output. If it is left to its default value (ANSI), the 'file.encoding', 'sun.stdout.encoding' and 'sun.stderr.encoding' system properties can be used to specify a different encoding that the Wrapper will use to read the JVM output. However, if wrapper.lang.windows.encoding specifies an encoding other than 'ANSI', the system properties will not be accepted in the wrapper.java.additional.* properties, because the Wrapper would also need to use them. In such a situation the Wrapper will consider the configuration as invalid and will stop. You will be asked to choose between the Wrapper properties and the system properties.

wrapper.lang.unix.encoding

Compatibility : 3.5.35 Editions : Platforms : This property was introduced in 3.5.35 to replace the deprecated wrapper.lang.encoding property. Like wrapper.lang.encoding, the default value is the encoding of the locale set for the session that launched the Wrapper. Before using the encoding, the Wrapper will always make sure that the combination of the configured language and encoding exists as an installed locale on the system, and that any conversions from and to the configured encoding are supported. If the configuration is correct, the locale (language and encoding) of the Wrapper process will be updated, otherwise the Wrapper will attempt to combine the configured language with the encoding of the session that launched the Wrapper, or failing that, will not update the locale. Example: (set the encoding to eucJP) wrapper.lang=ja_JP wrapper.lang.unix.encoding=eucJP If you use the command 'locale -a' to list all installed locales of the system, you may notice that some of them have no encoding specified in their descriptive name. In fact, such locales have a default encoding which can be displayed by using the following command: Example: (display the default encoding) LANG=de_DE@euro locale charmap ISO-8859-15 In order to make the Wrapper use a locale with a default encoding, it is necessary to set wrapper.lang.encoding to the value of the default encoding. Example: (define a locale with its default encoding) wrapper.lang=de_DE@euro wrapper.lang.unix.encoding=ISO-8859-15 NOTE On some platforms you would need to change the locale before executing 'locale charmap'. On Mac OSX, 'locale charmap' will return an empty string when querying the default encoding of a locale. In this case, the encoding is assumed to be UTF-8. NOTE When setting a locale, some platforms (Linux, AIX) will ignore canonical dashes, punctuation, and case in the encoding notation. For example UTF-8 is equivalent to utf8. Other platforms will require the encodings to strictly match (Solaris, FreeBSD, HP-UX). Finally some platforms will require the dashes and punctuation to match but not necessarily the case (Mac OSX, ZOS). WARNING In order to properly display log outputs, the configured encoding must match with the terminal's encoding. There is no way for the Wrapper to know about the terminal encoding, as it is usually specified by an option of the terminal emulator and not by a locale variable. For example, the encoding of the Gnome terminal can be changed from the menu by selecting: Terminal -> Set Character Encoding. Unlike Windows, the compatibility between a language and the encoding is automatically verified by the fact that it is only possible to set a locale to one of those installed on the system, an installed locale being a set where the encoding is appropriate for the language and region settings it represents. Another difference with Windows is that the Wrapper usually doesn't need to pass the encoding to the JVM (through file.encoding), because the JVM automatically uses the locale encoding of the Wrapper process. However, since version 3.5.35 the JVM output encoding and default encoding can be set to different values by using wrapper.jvm.encoding, in which case the Wrapper will need to add both encodings to the arguments used when launching the JVM. For this reason it is not allowed to use wrapper.jvm.encoding together with 'file.encoding', 'sun.stdout.encoding' or 'sun.stderr.encoding' in the wrapper.java.additional.* properties (see wrapper.jvm.encoding for details).

Compatibility :	3.5.0
Editions :
Platforms :

This property sets the location of the language files. The default value is "../lang".

wrapper.lang.folder=lang

Please note that relative paths are relative to the location of the Wrapper binary, not the location from where the command has been launched nor the location of the configuration file.

Compatibility :	3.5.0
Editions :
Platforms :

This property sets the domain of the binary and the library mo files. If you want to rename the wrapper_XX.mo and wrapperjni_XX.mo file, you need to set this property accordingly.

wrapper.lang.domain=myapp

This will cause the Wrapper to look for myapp_XX.mo or myappjni_XX.mo file when loading the language resources.