Specifying Liberty bootstrap properties

Bootstrap properties initialize the runtime environment for a particular server. Generally, they are attributes that affect the configuration and initialization of the runtime core.

For the latest documentation about Liberty bootstrap properties, see the Open Liberty website.

About this task

Bootstrap properties are set in a text file named bootstrap.properties. This file is not required, so it does not exist unless you create it. You must create this file in the server directory, which also contains the configuration root file server.xml. By default, the server directory is usr/servers/server_name. You can change the server directory as described in Customizing the Liberty environment.

You can create a bootstrap.properties file by using the editor in WebSphere® Application Server Developer Tools for Eclipse. From the Servers view, right-click on the server you want to configure, then select New, then Server Environment File, then bootstrap.properties, and the file is created from a template and opened in an editor. Along with the server.xml and server.env files, the bootstrap.properties file appears in the Servers view under the server that it is associated with and can be edited by double-clicking it.

You can edit the bootstrap.properties file by using a text editor or the editor in the WebSphere Application Server Developer Tools for Eclipse.

If you update the bootstrap.properties file, you must restart the server for the changes to take effect.

The bootstrap.properties file contains two types of properties:

A small, predefined set of initialization properties.
Any custom properties that you choose to define. You can then use these custom properties as variables in other configuration files such as server.xml and included files.

Procedure

Use predefined properties to configure trace and logging.
For example:
- To change the name of your trace file, specify the property com.ibm.ws.logging.trace.file.name with a file name of your choice, as follows:
```
com.ibm.ws.logging.trace.file.name = trace.log
```
- To enable binary logging, specify the websphere.log.provider property as follows:
```
websphere.log.provider = binaryLogging-1.0
```
For a list of the predefined properties for trace and logging, see Logging and Trace.
Use predefined properties for OSGi framework diagnostics.
For example, set the port for the OSGi console as follows:
```
osgi.console = 5678
```
For more information, see Using an OSGi console
Use predefined properties for OSGi framework extensions.

Specify the org.osgi.framework.bootdelegation if this property is required by external monitoring tools. The value is a comma-delimited list of packages.
Use predefined properties for configuration password encryption. For more information, see information about limits to protection through password encryption.
Use custom properties to define the default ports for web applications.

You can share server.xml and use XML configuration files across various development environments that allow machine- or environment-specific customization. For example:
1. Specify the properties default.http.port and default.https.port in the bootstrap.properties file:
```
default.http.port = 9081
default.https.port = 9444
```
  Note: If you do not specify the properties, the default HTTP port is 9080 and HTTPS ports is 9443. To override the default HTTP endpoint definition, set the id attribute of the httpEndpoint element to defaultHttpEndpoint in the server configuration.
2. Use the following properties in the server.xml configuration file:
```
<httpEndpoint id="defaultHttpEndpoint"
host="*"
httpPort="${default.http.port}"
httpsPort="${default.https.port}" />
```
  Note: host="*" means to listen on all adapters. By default, the server is listening only on address 127.0.0.1/localhost. You can also use the host property to specify a single IP address, and then the system listens only on the specified adapter.
Use custom properties to set the command port.
Set the command port to enable the server script to communicate with the running Liberty server and request certain operations, such as stopping the Liberty server or issuing a Java™ dump. For security, the command port cannot be accessed remotely, and clients must have read/write access to the server output directory to be authorized to issue commands.

By default, the Liberty server acquires an ephemeral port to be used by the command listener.

If you start the Liberty server from the shell script on z/OS®, by default the Liberty server acquires an ephemeral port to be used by the command listener. If you start the Liberty server as a started task on z/OS, by default the command port is initially disabled, and all server administration tasks are accomplished by using modify commands that are issued to the z/OS operator console. These commands are described in Administering Liberty on z/OS.

You can override the default behavior of the Liberty server by using the command.port property.

Valid values

-1

Command port is disabled.

0

Ephemeral port is chosen at run time.

1-65535

User-specified port.

Default value

0

Ephemeral port is chosen at run time.

If server is started from the shell script on z/OS, ephemeral port is chosen at run time.

-1

If server is started as a started task on z/OS, command port is disabled.
Note:
- You are discouraged from disabling the command port. If you disable the command port, you cannot use the server script to request some operations, for example, stopping the Liberty server or issuing a Java dump.
- You are discouraged from disabling the command port unless the server is running as a started task on z/OS. If you disable the command port, you cannot use the server script to request some operations, for example, stopping the Liberty server or issuing a Java dump.
Use custom properties to configure server start wait time.

You can increase the server start wait time beyond the product default setting by adding the server.start.wait.time property to the boostrap.properties file. The server.start.wait.time is specified in seconds.
1. Specify the server.start.wait.time property in the bootstrap.properties file.
  The following example sets the server start time to 25 seconds.
```
server.start.wait.time = 25
```
  This property defines how much time (in this example, 25 seconds) the start process can wait for the initiation of the main server process.
  Restriction: This property does not apply when the server is started with the server run command.
  
  If you do not add the server.start.wait.time property to the bootstrap.properties file, the default server start wait time is internally set to 30 seconds.
To apply the changes, restart the server.