Directory locations
Directory or file Property Description wlp/ wlp.install.dir Root of installation +- bin/
Scripts for managing the installation. For example, server. +- clients/
Liberty profile 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 the Liberty profile +- javadoc/
Java document archives +- spec/
Public specification APIs available for both compile and run time by default +- third-party/
Third-party APIs 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 the Liberty profile +- javadoc/
Java document archives for SPI +- spec/
Public specification SPIs available for both compile and run time by default +- tools/
Ant plug-in +- etc/
User customized server variables that apply to all servers (optional) +- server.env
Default server 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 +- 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 +- 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) +- 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) We can use the properties that are associated with each directory, if any, to specify file locations when we configure the server. For an example, see Deploy applications to the Liberty profile.
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 the choice, using the jndiEntry configuration elements in server.xml, 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 Use 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}");
Parent topic: Set up the Liberty profileTasks:
- Deploy applications to the Liberty profile
- Specify Liberty profile bootstrap properties
- Control dynamic updates
- Use include elements in configuration files
- Customize the Liberty profile environment
- Tune the Liberty profile
- Configure session persistence