+

Search Tips   |   Advanced Search

Deploy applications to the Liberty profile


Overview

We can deploy web applications or OSGi applications to the Liberty profile. We deploy an application by either dropping the application into a previously-defined "dropins" directory, or by adding an application entry to the server configuration.

This topic assumes that we have not disabled dynamic updates to the runtime configuration.

By default, the "dropins" directory is automatically monitored. If we drop an application into this directory, the application is automatically deployed on the server. Similarly, if the application is deleted from the directory, the application is automatically removed from the server. The "dropins" directory can be used for applications that do not require additional configuration, such as security role mapping. If we put the applications in the "dropins" directory, we must not include an entry for the application in the server configuration. Otherwise, the server will try to load the application twice and an error might occur. For applications that are not in the "dropins" directory, we specify the location using an application entry in the server configuration. The location can be on the file system or at a URL.

The application can be packaged as an archive file, a directory, or as a loose application where files are in multiple locations.

For applications in the "dropins" directory, the file name and file extension are used by the application monitor to determine the type of application, and to generate the application id and application name. For example, if the archive file or directory is named snoop.war, the application monitor assumes that the application is a web application and that the application id and application name is "snoop". For configured applications, the application type and name are specified.

See Directory locations.

  • Versioning is not possible for applications in the "dropins" directory.


    Deploy applications

    • Deploy an application by dropping it into the dropins directory.

      For example, using the default directory structure, to deploy an application we drop it into...

      ...that is...

        wlp/usr/servers/server_name/dropins

      We can deploy the application in any of the following ways:

      • Place the archive file with its identifying suffix (.ear, .war, and so on) directly into the /dropins directory. For example

      • Extract the archive file into a directory named with the application name and the identifying suffix. For example

      • Place the archive file or the extracted archive into a subdirectory named with the identifying suffix. For example

    • Deploy an application by adding it to the server configuration file.

      In server.xml, configure the following attributes for the application:

      id Must be unique and is used internally by the server.
      name Must be unique and depending on the application. The value of name might be used as the context-root of the application.
      type Type of the application. The supported application types are war, ear and eba.
      location Location of the application. It can be an absolute path or a URL which we can download the application from. It can also be the file name of the application (including file extension if any).

      If the application is available on the file system, the location can either be the full path name or a simple file name. If the location does not include the full path, the application manager looks for the application in both...

      If the application is available at a URL, the application manager downloads the application to a temporary folder inside the server work area, then starts the application.

      The location specified for a configured application should not be in the "dropins" directory. If we drop an application into the "dropins" directory, and also specify the location in server.xml, we are telling the server to deploy the application twice.

      In the following two examples, the location is the file system. If the location is a URL, enter the URL in the location field.

      The second example does not include the full path. In this case, we must put the application in one of the following locations:

      ${server.config.dir}/apps server_directory/user/servers/server_name/apps
      ${shared.app.dir} liberty_install_location/usr/shared/apps

    We can deploy the application to the file system in either of the following ways:

    • Place the archive file with its identifying suffix (.ear, .war, and so on) directly into the chosen location. For example...

        application_directory_path/myApp.war

    • Extract the archive file into a subdirectory of the chosen location, named with the application name and the identifying suffix. For example...

        application_directory_path/myApp.war/WEB-INF/...

    • We must create the server-level apps directory, whereas the shared apps directory is present by default.

    • The application element can be set before or after the server has started. If the element is set after the server has started, the changes are picked up dynamically.

  • Remove an application.

    For applications included in the server configuration, remove the reference to the application from server.xml. The application is then automatically removed from the server.

    For applications deployed to the "dropins" directory, delete the application from the directory. The application is then automatically removed from the server.

    To uninstall all applications that are in the "dropins" directory, set the application monitor dropinsEnabled property to false.


    What to do next

    For deployed applications, we can configure whether application monitoring is enabled and how often to check for updates to applications. For the "dropins" directory, configure name and location, and choose whether to deploy applications in the directory.


    Subtopics

    Tasks:

    1. Add and run an application on the Liberty profile using developer tools.
    2. Control dynamic updates
    3. Directory locations
    4. Configuration elements in server.xml