Liberty Profile

Previous | Home | Next

Liberty Profile

The Liberty profile is a new dynamic profile of WAS V8.5 that provisions only the features required by the applications.
For example, if an application requires just a servlet engine, Liberty profile can be configured to only start...

WAS kernel
HTTP endpoint for connection
Web container

This improves the server start time and results in a smaller footprint because only the required elements of the Java Enterprise Edition stack are enabled.
If the application needs additional features, such as database connectivity, the Liberty profile configuration can be dynamically modified to include the JDBC feature without the need of a server restart.
Key features...

Dynamic and flexible run time that loads only what the application needs
Quick startup time (couple of seconds with a basic web application)
Simplified configuration that can use a single file

Uses WAS runtime components, allowing compatibility between Liberty profile and full profile
Support of important Java Platform features, such as Java Persistence API
Support of the security mechanisms, including the LDAP registries
Easy Liberty profile packaging and distribution
Development tools support for Eclipse and Rational Application Developer
Support for Mac OS X and z/OS platforms

Architecture

A dynamic and composable runtime is the key characteristics of the Liberty profile. It is achieved using the OSGi framework as the foundation for the services that manage the component lifecycle.

WAS V8.5 Liberty Profile uses JRE version 6 or higher.The Liberty profile comprises of the Liberty profile kernel, and any number of optional features, run inside of a single JVM process. Most of the kernel runs as OSGi bundles within an OSGi framework.
The server is started, the launcher bootstraps the kernel and starts the OSGi framework. The server configuration is parsed, and features are loaded by the feature manager. The kernel makes extensive use of OSGi services to provide a highly-dynamic runtime. System configuration is managed by the OSGi Configuration Admin service, and an OSGi Declarative Services component is used to manage the lifecycle of system services. Application and configuration file changes are detected by the file monitor service. The file monitor service detects changes that are then reflected in real-time updates.
OSGi Declarative Services is used so that functions can be decomposed into discrete services, which are activated only when needed. This helps the runtime to be late and lazy, keeping the footprint small and the startup fast. Declarative services are added or removed from the OSGi service registry, and dependencies between services can be resolved without loading implementation classes. Service activation can be delayed until a service is actually used, when the service reference is resolved. Configuration for each service is injected as the service is activated and is reinjected if the configuration is later modified.
The Liberty profile capabilities come from the WAS V8.5 full profile.
The key difference between the full profile and the Liberty profile is the packaging of Liberty into OSGi modules to allow the composing of the Liberty profile. The stack of the Liberty profile shares the same code with the full profile.

When developing applications on Liberty Profile, developers can be confident their code runs in exactly the same way that it runs on the full WAS full profile. Also, because the tested and proven functionality from the WAS full profile is used in the Liberty profile, it is a solid foundation as a production environment.

Feature management

Features are the units of functions that control the parts of the runtime environment that are loaded into a Liberty profile server. The jsp-2.2 feature adds basic support for servlets and JSP applications. However there are a variety of other features that can be used in the Liberty profile. Any feature supplied with the Liberty profile package can be added.
Some features include other features. For example the jsp-2.2 feature already includes the servlet-3.0. This is because to run the JSP page, you need a web container. Similarly the jsf-2.0 feature includes the jsp-2.2 feature.
The Liberty runtime environment skips any features that are already loaded, and it is acceptable to include a feature twice or to include a feature enabled by another feature.

Features are specified in server.xml. Each feature has its own version identifier, so multiple versions of the same feature can run in the same server.
The OSGi Configuration Admin service reads server.xml and injects the feature configuration into the feature manager service. The feature manager then maps each feature name to a list of bundles that provide the feature. With all of the appropriate bundles ready, feature manager installs and starts the features in the OSGi framework. The feature manager also responds to configuration changes by dynamically adding and removing features while the server is running.

Directory structure

Not all files or folders appear after the installation of the Liberty profile. Many of the files are optional and are not required by the Liberty runtime environment.

The most important Liberty profile directories are:

Directory Description
bin Scripts used to manage the Liberty profile server instance
server Create, start, stop, package, or create dumps of the Liberty profile.
securityUtility Generate keystores or encode passwords.
etc Customize the whole Liberty profile installation. Settings will apply to all Liberty profile servers. If there is no etc directory or configuration files, default settings for the JVM and Liberty runtime are used.
jvm.options Customize default JVM runtime parameters
server.env Configure default Liberty profile server environment variables
lib Liberty profile libraries.
templates Samples for specific configurations and a sample server.xml file for the Liberty profile.
usr Server instances with their configuration and applications and any resources that can be shared between servers.

In addition to the Liberty profile structure, there is a set of directories and files for the Liberty profile server instance.

Liberty profile server instance files and directory structure...

Directory Description
apps Optional. It can contain deployed applications or application descriptors, if they are deployed using the WebSphere Developer Tools. Default location for the Liberty profile server to look for applications.
logs Contains the logs produced by the Liberty profile server. By default, this is the place where the trace or message logs are written. It also contains the First Failure Data Captures (FFDC).
resources Contains additional resources for the Liberty profile server instance, for example, keystores generated by the Liberty profile server are located at this directory.
tranlog Contains transactional logs produced by the server runtime and the applications. The transactional logs are used to commit or rollback transactional resources.
workarea Created during the first server run. It contains the Liberty profile server operational files.

Configuration files
Runtime services provide their configuration defaults so the configuration specify is kept to a minimum. At server startup, or when the user configuration files are changed, the kernel parses the configuration and applies it over the system defaults. The set of configuration properties belonging to each service is injected into the service each time the configuration is updated.
A Liberty profile server can be customized using a few files:

server.xml Required. Primary configuration file. Has simple XML format suitable for text editors.
bootstrap.properties Optional. Customize kernel bootstrap process or specify additional variables for use in server.xml.
jvm.options Optional. Specify JVM options for the server. If is present, it supersedes /etc/jvm.options
server.env Optional. Customize environment variables used to launch the server. If both this file and /etc/server.env are present, the contents of both are merged together with values specific to the server superseding values specified for the install.

The optional files are not created by default, whereas server.xml is always created.

Working with server.xml

The only required entry in server.xml is the server tag, which defines a server configuration scope.
<server />
Add new configuration

Typical configuration looks like...
<server description="server2">

    <featureManager>
        <feature>jsp-2.2</feature>
    </featureManager>
    
    <httpEndpoint host="localhost" 
                  httpPort="9081" 
                  httpsPort="9444" 
                  id="defaultHttpEndpoint"/>
    
     <application id="ITSOWebCustomerCredit" 
                  location="/opt/myapps/ITSOWebCustomerCredit.war" 
                  name="ITSOWebCustomerCredit"
                  type="war"/>

</server>
The feature section is where you configure the server runtime to use the required features for the applications.
To add a new feature add a new line to server.xml. After the file is saved, the file monitor service discovers the change, and the Liberty profile server applies new features to the runtime.

Using include syntax

The server.xml file also allows you to configure other parameters, such as the server listening ports or datasources. Although keeping all of the configuration for a server in a single file eases the complexity of server configuration, the file can grow to a substantial size.
This is one reason to make use of the include syntax to move some of the configuration into other XML files.
The included XML files can also include other configuration files.

Splitting the configuration of the Liberty profile into multiple files

The monitor service detects changes to any of the included files, not only the main server.xml file.
The include syntax provides a flexible way to share all or part of a configuration between different servers on the same or even on different host machines. We can control how the configuration is structured and which pieces are shared by which servers. Included XML files can be on the local file system or hosted in the network.
Using the include tag, we can add a data source definition.
<server description="server2 main configuration">

    <featureManager>
        <feature>jsp-2.2</feature>
    </featureManager>
    
    <httpEndpoint host="localhost" 
                  httpPort="9080" 
                  httpsPort="9443"
                  id="defaultHttpEndpoint"/>
    
    
    <include location="datasourcesConfig.xml"/>
    
    <application id="ITSOWebCustomerCredit" 
                 location="ITSOWebCustomerCredit.war"
                 name="ITSOWebCustomerCredit" 
                 type="war"/>
</server>
The configuration now includes an additional datasourcesConfig.xml file. The location is a direct path. If you use just the name of the file, both the source and the included file have to be in the same directory.
<server description="database configuration for server2">

    <featureManager>
        <feature>jdbc-4.0</feature>
    </featureManager>

    <jdbcDriver 
                libraryRef="DerbyLib"/>

    <library filesetRef="DerbyFileset" 
             id="DerbyLib"/>

    <fileset dir="C:/Derby/lib" 
             
             includes="derby.jar"/>

    <dataSource 
                   jdbcDriverRef="DerbyEmbedded"
                   jndiName="jdbc/MyDataSource" 
                   syncQueryTimeoutWithTransactionTimeout="false"
                   type="javax.sql.DataSource">

        <properties.derby.embedded createDatabase="create" 
                                   databaseName="CUSTDB1"/>
    </dataSource>

</server>
Notice the included file also has to contain the server tags. It also contains the jdbc-4.0 feature along with the data source definition, which are merged by the OSGi Configuration Admin Service as a single configuration.
Alternatively, instead of pointing to a file on a file share, we can use an URL under which it is accessible, for example:
<include location="http://myfileserver/config/server2/datasourcesConfig.xml"/>
Using variables

We can use variables in the configuration to avoid hard coding multiple, same values. To define a global variable in the configuration, use the variable tag. The following example shows a sample variable, myGlobalVariable, with a JNDI name (variables can be any string).
<variable name="myGlobalVariable" value="jdbc/MyDataSource" />
This variable can be defined in the server.xml or any of the included files. To use this variable, we can rewrite the data source definition from Example 6-4.
<dataSource 
            jdbcDriverRef="DerbyEmbedded"
            jndiName="${myGlobalVariable}" 
            syncQueryTimeoutWithTransactionTimeout="false"
            type="javax.sql.DataSource">

    <properties.derby.embedded createDatabase="create" 
                               databaseName="CUSTDB1"/>

</dataSource>
Using WebSphere Developer Tools to work with the configuration

We can use the WebSphere Developer Tools to work with server.xml. Wizards and windows in the Eclipse workbench help to configure all of the server properties. To configure server.xml using WebSphere Developer Tools, double-click the Server Configuration.

The current server configuration will be shown in a new window with all of its features and properties listed

Configuring a Liberty profile server data source using the WebSphere Developer Tools

Instead of typing the name of each of the configuration elements or their numerous properties, we can simply press Add, and WebSphere Developer Tools will guide you with the possible values and properties to configure.

Working with bootstrap.properties file

The bootstrap.properties file is the second file that can be used for the Liberty profile server configuration. Changes to this file require the server to be restarted. By default this file is not generated when you create the Liberty profile server instance. To use this file, you first have to create it.
Place this file in the main server directory along side server.xml. The bootstrap properties are generally used to initialize the runtime environment for a particular server.
# some variable
myVariable = C:/tmp/logs

# trace logging settings com.ibm.ws.logging.trace.specification = *=all=enabled
To configure bootstrap.properties use key-value pairs. To make comments, use the # sign.
We can also use bootstrap.properties to configure our own variables, which then can be used in server.xml. This is especially helpful for file paths. To use a variable configured in the bootstrap.properties, add the following line to bootstrap.properties to define the path to the Derby database:
derbyInstallDir=C:/Derby
Next, in the server.xml, replace the fileset line with the following line:
<fileset dir="${derbyInstallDir}/lib" 
         
         includes="derby.jar"/>
Replacing the fileset line allows you to manage the direct paths or variable values from a single place; however, keep in mind the Liberty profile server requires a restart to reflect the changes made in bootstrap.properties. To be able to change variables dynamically, keep your variables in the dynamic server.xml file.

Directory	Description
bin	Scripts used to manage the Liberty profile server instance
server	Create, start, stop, package, or create dumps of the Liberty profile.
securityUtility	Generate keystores or encode passwords.
etc	Customize the whole Liberty profile installation. Settings will apply to all Liberty profile servers. If there is no etc directory or configuration files, default settings for the JVM and Liberty runtime are used.
jvm.options	Customize default JVM runtime parameters
server.env	Configure default Liberty profile server environment variables
lib	Liberty profile libraries.
templates	Samples for specific configurations and a sample server.xml file for the Liberty profile.
usr	Server instances with their configuration and applications and any resources that can be shared between servers.

Directory	Description
apps	Optional. It can contain deployed applications or application descriptors, if they are deployed using the WebSphere Developer Tools. Default location for the Liberty profile server to look for applications.
logs	Contains the logs produced by the Liberty profile server. By default, this is the place where the trace or message logs are written. It also contains the First Failure Data Captures (FFDC).
resources	Contains additional resources for the Liberty profile server instance, for example, keystores generated by the Liberty profile server are located at this directory.
tranlog	Contains transactional logs produced by the server runtime and the applications. The transactional logs are used to commit or rollback transactional resources.
workarea	Created during the first server run. It contains the Liberty profile server operational files.

server.xml	Required. Primary configuration file. Has simple XML format suitable for text editors.
bootstrap.properties	Optional. Customize kernel bootstrap process or specify additional variables for use in server.xml.
jvm.options	Optional. Specify JVM options for the server. If is present, it supersedes /etc/jvm.options
server.env	Optional. Customize environment variables used to launch the server. If both this file and /etc/server.env are present, the contents of both are merged together with values specific to the server superseding values specified for the install.