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.

Open Liberty For the latest documentation about Liberty directory locations and properties, see the Open Liberty website.

Table 1. Runtime environment default directory structure. Column 1 contains a file and directory tree. If a directory has a property that is associated with it, this is given in column 2. A description of each file or directory is given in Column 3.
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, xmlns:wlp="antlib:net.wasdev.wlp.ant. For more information about the open source Ant plug-in for Liberty, see the GitHub repository.

+- 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}");