Liberty: Directory locations and properties
In Liberty, many directories have properties that are associated with them. These properties can be used to specify file locations when you configure the server.
For the latest
documentation about Liberty directory
locations and properties, see the Open Liberty website.
| Directory or file | Property | Description |
|---|---|---|
wlp/ |
wlp.install.dir |
Root of installation |
+- bin/ |
Scripts for managing the installation. For example, server. |
|
+- clients/ |
Liberty
client and thin client libraries. For example restConnector.jar. |
|
+- jython/ |
Jython-based scripts | |
+- dev/ |
Root for developer resources (APIs, SPIs, specifications, and tools) | |
+- api/ |
Public APIs available for both compile and run time by default | |
+- ibm/ |
APIs available in Liberty | |
+- javadoc/ |
Java™ document archives | |
+- spec/ |
Public specification APIs available for both compile and run time by default | |
+- third-party/ |
Third-party APIs that are available at compile time by default and
must be specified in the configuration using the apiTypeVisibility attribute of the
classloader element for applications at run time. |
|
+- spi/ |
Public SPIs available for both compile and run time by default | |
+- ibm/ |
SPIs available in Liberty | |
+- javadoc/ |
Java document archives for SPI | |
+- spec/ |
Public specification SPIs available for both compile and run time by default | |
+- tools/ |
Ant plug-in for
Liberty The wlp-anttasks.jar file in the
tools directory was removed
from Liberty in 19.0.0.3. An open source Ant
plug-in with more tasks for Liberty is
available. The more recent Ant plug-in has a different antlib namespace,
|
|
+- etc/ |
User customized server variables that apply to all servers (optional) | |
+- server.env |
Default server script environment variables (optional) | |
+- client.env |
Default client script environment variables (optional) | |
+- jvm.options |
Default JVM options (optional) | |
+- lafiles/ |
License information files | |
+- lib/ |
Platform runtime environment | |
+- templates/ |
Runtime customization templates and examples | |
+- server/ |
Server template when creating a server | |
+- client/ |
Client template when creating a client | |
+- usr/ |
wlp.user.dir |
User directory |
+- extension/ |
usr.extension.dir |
User-developed features |
+- shared/ |
||
+- apps/ |
shared.app.dir |
Shared applications |
+- config/ |
shared.config.dir |
Shared configuration files |
+- resources/ |
shared.resource.dir |
Shared resource definitions: adapters, data sources |
+- stackGroups/ |
shared.stackgroup.dir |
Shared stack groups for remote deployment of packages and installables |
+- servers/ |
Shared servers directory | |
+- server_name |
server.config.dir |
Server configuration directory. Use ${server.config.dir} to reference server-specific configuration (applications). |
+- bootstrap.properties |
Server bootstrap properties (optional) | |
+-
jvm.options |
Server JVM options, which replace the values in wlp/etc/jvm.options (optional) | |
+-
server.env |
Server script environment variables, which are merged with wlp/etc/server.env (optional) | |
+- server.xml |
Server configuration overlays (required) | |
+- apps/ |
Server configuration for applications | |
+- dropins/ |
Server default application dropins folder (optional) | |
+-
application_name |
Application folder or archive (optional) | |
+- configDropins/ |
Server configuration dropins folder (optional) | |
+-
defaults |
Default server configuration dropins folder (optional) | |
+-
overrides |
Server configuration overrides dropins folder (optional) | |
+- server_name |
server.output.dir |
Server output directory. Use ${server.output.dir} to describe artifacts generated by the server (log files and workarea). |
+- logs/ |
Server log files, including FFDC logs (directory is present after server is first run) | |
+- console.log |
Basic server status and operations messages | |
+-
trace_timestamp.log |
Time-stamped trace messages, with the level of detail determined by the current tracing configuration | |
+- ffdc/ |
First Failure Data Capture (FFDC) output directory | |
+-
ffdc_timestamp/ |
First Failure Data Capture (FFDC) output that typically includes selective memory dumps of diagnostic data related to the failure of a requested operation | |
+- workarea/ |
Files created by the server as it operates (directory is present after server is first run) | |
+- clients/ |
Shared clients directory | |
+- client_name |
Client configuration directory. | |
+- bootstrap.properties |
Client bootstrap properties (optional) | |
+-
client.jvm.options |
Client JVM options, which replace the values in wlp/etc/client.jvm.options (optional) | |
+- client.xml |
Client configuration overlays (required) | |
+- apps/ |
Client configuration for applications | |
+- logs/ |
Client log files, including FFDC logs (directory is present after client is first run) | |
+-
trace_timestamp.log |
Time-stamped trace messages, with the level of detail determined by the current tracing configuration | |
+- ffdc/ |
First Failure Data Capture (FFDC) output directory | |
+-
ffdc_timestamp/ |
First Failure Data Capture (FFDC) output that typically includes selective memory dumps of diagnostic data related to the failure of a requested operation | |
+- workarea/ |
Files created by the client as it operates (directory is present after client is first run) |
You can use the properties that are associated with each directory, if any, to specify file locations when you configure the server. For an example, see Deploying applications in Liberty.
Tip: To ensure configuration portability, use the most specific property that is
appropriate, and do not rely on the relationship between resources. For example, in some
configurations the installation location,
${wlp.install.dir} might not be the parent of the
customized instance ${wlp.user.dir}.Programmatic access to location properties
Location properties can be bound into the JNDI namespace under names of your choice, using the jndiEntry configuration elements in the server.xml file, for example:
<jndiEntry jndiName="serverName" value="${wlp.server.name}"/>Such entries are accessible by any code that runs in the server (applications, shared libraries or features) through a JNDI lookup:
Object serverName = new InitialContext().lookup("serverName");For more information on how to use JNDI entries in configuration, see Using JNDI binding for constants from the server configuration files.
Feature code can also use a system programming interface (SPI) provided by the kernel to resolve the values of these properties, for example:
ServiceReference <WsLocationAdmin>locationAdminRef = bundleContext.getServiceReference(WsLocationAdmin.class);
WsLocationAdmin locationAdmin = bundleContext.getService(locationAdminRef);
String serverName = locationAdmin.resolveString("${wlp.server.name}");