InfoCenter Home >
6: Administer applications >
6.6: Tools and resources quick reference >
6.6.8: Administering Web applications (overview)

6.6.8: Administering Web applications (overview)

The servlets and JavaServer Pages (JSP) files in a Web application share a servlet context, meaning they share data and information about the execution environment, including a Web application classpath.

Approaches to configuring Web applications

There are two basic approaches to configuring Web applications. The administrator can configure a Web application:

  • From the bottom up
  • From the top down

To configure a Web application from the bottom up, the administrator can first explicitly configure the individual servlets that will eventually comprise the Web applications. When configuring a servlet, the administrator specifies the name and location of the servlet class file, and other information necessary for enabling the administrator to manage the servlet.

The administrator can combine one or more explicitly-defined servlets and Web resources into an Web application, allowing them to be managed as a logical unit (the Web application).

Because they are explicitly configured, the servlets can also be managed individually. For example, the administrator can unload a servlet from the Web application without causing the rest of the application to become unavailable to users.

The administrator can also configure a Web application from the top down. This technique might be familiar to an administrator who has used Web server products or IBM WebSphere Application Server Version 2.

Instead of explicitly defining each component (servlet, Web page, and so on), the administrator specifies the directories in which he or she plans to place the components of each type.

In the simplest case, each Web application has one directory for servlets and another for Web resources. Any servlet placed in the designated servlet directory becomes part of the Web application, and similarly any Web pages and JavaServer Pages (JSP) files are picked up from the designated Web resource directory.

Because the servlets are not explicitly defined, they cannot be managed or monitored individually.

Web applications inside enterprise applications

A Web application can be part of an enterprise application (an "application" for short). In the simplest case, an enterprise application is simply a "wrapper" for a Web application -- the files that comprise the application are exactly the same files that comprise the Web application.

In such a case, why bother to add a Web application to an enterprise application? An enterprise application help file discusses the benefits.

In a more complex case, an application might contain multiple Web applications and (in the case of IBM WebSphere Application Server Advanced Edition) some enterprise beans as well.

Configuring Web applications directly in WebSphere systems administration

The administrator should understand a few main settings as he or she configures Web applications:

  • Classpath

    Specifies where to find the servlets that belong to the application.

    The classpath can specify a directory containing servlets, or can specify each servlet explicitly.

    It can also specify the location of other files supporting the Web application.

  • Document root

    Specifies where to find the Web pages and JSP files belonging to the Web application.

  • Web path

    Combined with the virtual host, specifies what users will type in a Web browser to access the Web application.

The administrator can also specify properties such as:

  • Servlet filtering parameters

  • Affiliation with a virtual host

  • Whether to reload servlets whose class files have changed

  • Whether to temporarily suspend the Web application from use

  • Servlet context attributes

Classpath considerations

An important classpath-related setting to note is the Module Visibility. This application server setting impacts the portability of applications and standalone modules from other WebSphere Application Server versions and editions. If your existing module does not run as-is when you transfer it to Version 4.0, you might need to reassemble an existing module or change the module visibility setting.

See the information on setting classpaths for a full discussion of classpath considerations. See the application server property reference for information about the module visibility setting.

Identifying a welcome page for the Web application

The default welcome page for your Web application is assumed to be named index.html. For example, if you have an application with a Web path of:

/webapp/myapp
then the default page named index.html can be implicitly accessed using the following URL:
http://hostname/webapp/myapp

Applies to Fix Pack 2 and later  Version 3.5.2 introduces a Welcome Files setting, as described by the Servlet 2.2 specification. See the Web application properties for details.

New in Fix Pack 2  Converting WAR files

Version 3.5.2 (Fix Pack 2 applied to Version 3.5 base) introduces a new way to introduce Web applications into the WebSphere environment. The product now consumes and converts WAR files into WebSphere configurations.

Alternatively, you can continue to configure Web applications directly in WebSphere Application Server systems administration. The latter allows you to add WebSphere servlets to your Web applications to extend their functionality.

You can use either the Java console (WebSphere Administrative Console) or command line programs to convert WAR files.

Utilizing servlets available from WebSphere

See section 4.2.1.2.3 for information about adding complimentary WebSphere servlets to Web applications to provide functions such as JSP enablement, error reporting, file serving, and the ability to invoke servlets by classname.

Go to previous article: Property files pertaining to servlet engines Go to next article: Web application properties

 

 
Go to previous article: Property files pertaining to servlet engines Go to next article: Web application properties