WAS v8.5 > Deploy applications

Deploy applications to the Liberty profile

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

We can deploy applications as described in this topic, or as described in Add and running an application on the Liberty profile using WebSphere Studio.

This topic assumes that we have not disabled dynamic updates to the runtime configuration, as described in Liberty profile dynamic updates. 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. We do not have to include the application entry or any relevant information in the server configuration. 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.

Your application can be packaged as an archive file or as a directory. 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 name and the context-root for web applications. For example, if the archive file or directory is named snoop.war, the application monitor assumes the application is a web application, the application name is "snoop", and the context-root is also snoop. For configured applications, we specify the application type and name, and if the application is a web application, the application name is also used as the context-root.

For more information about the default directory structure and the properties that are associated with directories (for example server.config.dir), see Liberty profile: Directory locations and properties.

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

  For example, using the default directory structure, to deploy an application you drop it into the ${server.config.dir}/dropins directory (, wlp/usr/servers/worklightServer/dropins).

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

  Configure the application element in the server.xml configuration file. See Liberty profile: Configuration elements in server.xml. You must 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. It might be used as the context-root of the application. For more information on how the context-root is set for an application, see Deploy a web application to the Liberty profile.

  type

  Specifies the 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 ${server.config.dir}/apps and ${shared.app.dir}. 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, you 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.

  < application name="ImpactEBA" type="eba" location="D:/apps/ImpactEBA.eba"/> < application name="ImpactWeb" type="war" location="ImpactWeb.war"/>
  The second example does not include the full path. In this case, you must put the application in one of the following locations:
  • ${server.config.dir}/apps (that is, server_directory/user/servers/worklightServer/apps)
  • ${shared.app.dir} (, liberty_install_location/usr/shared/apps)
  • You must create the server-level apps directory, whereas the shared apps directory is present by default. See Liberty profile: Directory locations and properties for more information about the properties associated with the server directories.

  • 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 that are 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 as described in Liberty profile dynamic updates.

For all deployed applications, we can configure whether application monitoring is enabled and how often to check for updates to applications. For the "dropins" directory, we can also configure the name and location of the directory and choose whether to deploy the applications that are in the directory. See Liberty profile dynamic updates.

See also

• Add and running an application on the Liberty profile using WebSphere Studio
  We can add applications to the server by right-clicking on the server in the Servers view then selecting Add and Remove from the menu.
• Packaging a Liberty profile server
  From the command prompt we can create a compressed file containing a Liberty profile runtime environment, the files in the shared resources directory, a specific server, and the applications that are embedded in the server. We can also choose to exclude the runtime binaries from the compressed file.
• Use JNDI binding for constants from the server configuration files
  We can bind constants into the default JNDI namespace from the server configuration files using the jndiEntry element on the Liberty profile.
• Sharing common OSGi bundles for the Liberty profile
  We can share common OSGi bundles by placing them in a directory and configure server.xml for the server so that those common OSGi bundles are available to your enterprise applications.
• Deploy data access applications to the Liberty profile
  Deploying a data access application includes more than installing your WAR or enterprise archive (EAR) file onto a Liberty profile. Deployment can include tasks for configuring the data access resources of the server and overall runtime environment.
• Deploy a web application to the Liberty profile
  By deploying a helloworld.war application, we can learn how server configurations change in the Liberty profile.
• Deploy a JPA application to the Liberty profile
  To enable the Liberty profile to support an application that uses the Java™ Persistence API (JPA), you add the jpa-2.0 feature to server.xml. You also need to define persistence contexts and persistence units, and configure access to the entity manager and entity manager factory.
• Deploy web services applications to the Liberty profile
  By configuring Liberty features in server.xml, we can deploy web services applications to the Liberty profile.

Parent topic: The Liberty profile

Related

Liberty profile dynamic updates

Reference:

Liberty profile: Directory locations and properties
Liberty profile: Configuration elements in server.xml

|