Previous | Home | Next


Managing applications

WAS V8.5 supports J2EE 1.3, J2EE 1.4, Java EE 5, and Java EE 6, which we refer to as enterprise applications. WAS V8.5 can run the following types of applications:

OSGi applications are built on an architecture for developing and deploying modular applications and libraries. OSGi applications are built using the OSGi API and deploying it into an OSGi container. WAS provides an OSGi container as part of its basic architecture.


Managing enterprise applications: Administrative console

To view and manage applications using the dmgr console, click...

In the window, you see the list of installed applications and options for performing application management tasks. Select one or more applications by selecting the box to the left of the application name and then click an action to perform. The exception to this action is the Install option, which installs a new application and requires no existing application to be selected

The following list describes the actions we can choose on this window after selecting an application:

Start Applications normally start when the server to which they are mapped starts. Exceptions to this situation include when the application is initially installed and when the application is stopped manually. To start an application, the application server containing the application must be started. If not, the application displays in the dmgr console as unavailable and we cannot start it. An application can also be started from the job manager console using the Start application job type.

Starting an application server starts the applications that are mapped to that server. The order in which the applications start depends on the startup order you assigned to each of them. The application with the lowest startup order value is started first. Applications that have the same order designation are started in no particular order. Enabling the parallel start option for the application server means to start applications with the same weight in parallel.

To view or change the application startup order, click...

    Applications | Application Types | WebSphere enterprise applications | application | Startup behavior

Stop We can stop an application manually without affecting the rest of the application server processes. This situation is common when you update an application or want to make it unavailable to users. We can also use the job manager console to stop an application using the Stop application job type.
Install The install option takes you through the process of installing a new enterprise application EAR file.
Uninstall Uninstall an application. This action removes it from the application servers and from the configuration repository. This action can be performed from the job manager using the Uninstall application job type.

When you uninstall an application and it is the only composite unit in a business-level application, the BLA is also deleted.

Update or Rollout Update Applications can be updated in several ways. The update options include full application, single module, single file, and partial application.
Remove file Remove a single file from an application.
Export Export an EAR file of the application.
Export DDL Export DDL files found in the application.
Export File Export individual files found in the application.


Preventing an enterprise application from starting on a server

By default, an application starts when the server starts. The only way to prevent this occurrence is to disable the application from running on the server.

To prevent an enterprise application from starting on a server:

  1. From the dmgr console, click...

      Applications | Application Types | WebSphere enterprise applications | application name | Detail Properties section | Target specific application status | server | Disable Auto Start

  2. Save the configuration.


Viewing application details

The dmgr console does not display the deployed servlets, JSPs, or EJBs directly on the dmgr console. However, we can use the dmgr console to display XML deployment descriptors for the enterprise application, web modules, and EJB modules.

To view the application deployment descriptor for an application:

  1. Click Applications | Application Types | WebSphere enterprise applications | application name | Detail Properties | Configuration tab | View Deployment Descriptor


Viewing EJB modules

To see the EJBs that are part of an enterprise application:

  1. Click Applications | Application Types | WebSphere enterprise applications | application name | Modules Items | Manage Modules | EJB module name

  2. Under Additional Properties, click View Deployment Descriptor to see the EJB deployment descriptor.


Viewing web modules

To see the servlets and JSPs that are part of an enterprise application:

  1. Click Applications | Application Types | WebSphere enterprise applications | application name | Modules Items section | Manage Modules | web module name

  2. Click View Deployment Descriptor to see the details of the web module content.


Finding a URL for a servlet or JSP

The URL for a servlet or JSP is the path used to access it from a browser. The URL is partly defined in the deployment descriptor provided in the EAR file and partly defined in the deployment descriptor for the web module containing the servlet or JSP.

To find the URL for a servlet or JSP:

  1. Find the context root of the web module containing the servlet.

  2. Find the URL for the servlet.

  3. Find the virtual host where the web module is installed.

  4. Find the server or cluster on which the application is installed.

  5. Find the aliases by which the virtual host is known.

  6. Combine the virtual host alias, context root, and URL pattern to form the URL request of the servlet/JSP.

For example, to look up the URL for the snoop servlet:

  1. Find the context root of the web module DefaultWebApplication of the DefaultApplication enterprise application. This web module contains the snoop servlet:

    1. Click Applications | Application Types | WebSphere enterprise applications.

    2. Click the application in which we are interested, which in our case is DefaultApplication.ear.

    3. On the Configuration tab, click Context Root for Web Modules in the Web Module Properties section. Notice the following items:

      • There is only one web module in this application, , the Default Web Application.
      • The context root is "/"

    4. Click OK to return to the DefaultApplication configuration.

  2. Find the URL for the snoop servlet:

    1. Locate the DefaultApplication configuration window, and in the Modules section, select Manage Modules.

    2. Click the Default Web Application web module to see the general properties.

    3. Under Additional Properties, click View Deployment Descriptor to display the web module properties window. The URL pattern for the snoop servlet starting from the web module context root is "/snoop/*"

      The web module context root is "/"

    4. As you navigate through the windows, a navigation path is displayed underneath the Messages area, which is the bread-crumb trail. Click DefaultApplication.ear to return to the application configuration page.

  3. Find the virtual host where the web module is installed:

    In the DefaultApplication configuration window, click Virtual hosts under the Web Module Properties section. This action displays all of the web modules contained in the enterprise application and the virtual hosts in which they were installed. The Default Web Application Web module is installed on the default_host virtual host.

  4. Find the server or cluster on which the application is installed:

    1. In the DefaultApplication configuration window, click Manage Modules under the Modules section.

    2. Click the Default Web Application module name.

    3. Under the Additional Properties section, click Target specific application status.

    4. Click the server name or cluster name listed as the target.

    5. Look for the WC_defaulthost and WC_defaulthost_secure port values for the server or for each server in case of a cluster configuration.

  5. Find the host aliases for the default_host virtual host:

    1. From the administration console navigation tree, click Environment | Virtual Hosts.

    2. Click default_host.

    3. Under Additional Properties, click Host Aliases. This action shows the list of aliases by which the default_host virtual host is known.

      The aliases are composed of a DNS host name and a port number. Combine aliases ports and the WC_defaulthost and WC_defaulthost_secure ports of the server.

      In the case of a cluster, you combine the ports of several servers. After ports are combined, an accurate list of aliases, based from where the applications are mapped to, can be generated. In our case, the host aliases for the default_host virtual host are *:80, *:443,*:9084, and *:9447, where “*” stands for any host name. Ports 80 and 443 are used for HTTP server (non-secure and secure port).

  6. Combine the virtual host alias, context root, and URL pattern to form the URL request of the snoop servlet. Requests for the servlet with any of the following URLs map to the default_host virtual host:

    • http://hostname:80/snoop
    • https://hostname:443/snoop
    • http://hostname:9084/snoop
    • https://hostname:9447/snoop