Skip navigation.
Downloads | Product Documentation | Support

Programming WebLogic HTTP Servlets

# Administration and Configuration

The following sections provide an overview of administration and configuration tasks for WebLogic HTTP servlets. For a complete discussion of servlet administration and configuration see Configuring Servlets.

This section discusses the following topics:

- Overview of WebLogic HTTP Servlet Administration
- Referencing a Servlet in a Web Application
- Directory Structure for Web Applications
- Servlet Security
- Servlet Development Tips
- Clustering Servlets

# Overview of WebLogic HTTP Servlet Administration

Consistent with the Java 2 Enterprise Edition standard, HTTP servlets are deployed as part of a Web Application. A Web Application is a grouping of application components, such as servlet classes, JavaServer Pages (JSP), static HTML pages, images, and utility classes.

In a Web Application the components are deployed using a standard directory structure. This directory structure can be archived into a file called a `.war` file and then deployed on WebLogic Server. Information about the resources and operating parameters of a Web Application are defined using two deployment descriptors, which are packaged with the Web Application.

## Using Deployment Descriptors to Configure and Deploy Servlets

The first deployment descriptor, `web.xml`, is defined in the Servlet 2.3 specification from Sun Microsystems and provides a standardized format that describes the Web Application. The second deployment descriptor, `weblogic.xml`, is a WebLogic-specific deployment descriptor that maps resources defined in the `web.xml` file to resources available in WebLogic Server, defines JSP behavior, and defines HTTP session parameters.

### web.xml (Web Application Deployment Descriptor)

In the Web Application deployment descriptor you define the following attributes for HTTP servlets:

- Servlet name
- Java class of the servlet
- Servlet initialization parameters
- Whether or not the `init()` method of the servlet is executed when WebLogic Server starts
- URL pattern which, if matched, will call this servlet
- Security
- MIME type
- Error pages
- References to EJBs
- References to other resources

For a complete discussion of creating the `web.xml` file, see Deployment Descriptors.

### weblogic.xml (Weblogic-Specific Deployment Descriptor)

In the WebLogic-specific deployment descriptor you define the following attributes for HTTP servlets:

- HTTP session configuration
- Cookie configuration
- URL pattern which, if matched, will call this servlet using a URL matching utility such as the The SimpleApacheURLMatchMap Utility included with WebLogic Server.
- EJB resource mapping
- JSP Configuration

For a complete discussion of creating the `weblogic.xml` file, see Writing Web Application Deployment Descriptors.

## WebLogic Server Administration Console

Use the WebLogic Server Administration Console to set the following parameters:

- HTTP parameters
- Log files
- URL rewriting
- Keep alive
- Default MIME types
- Clustering parameters
- URL mapping for virtual hosting

For more information see the following resources:

- Administration Console: Web Applications`.`
- Administration Console: " Virtual Hosts`.`

# Directory Structure for Web Applications

Use the following directory structure for all Web Applications:

>     Default WebApp/(Publicly available files, such as
>                         |  .jsp, .html, .jpg, .gif)
>                         |
>                         +WEB-INF/-+
>                                   |
>                                   + classes/(directory containing
>                                   |         Java classes including
>                                   |         servlets used by the
>                                   |         Web Application)
>                                   |
>                                   + lib/(directory containing
>                                   |       jar files used by the
>                                   |       Web Application)
>                                   |
>                                   + web.xml
>                                   |
>                                   + weblogic.xml

# Referencing a Servlet in a Web Application

The URL used to reference a servlet in a Web Application is constructed as follows:

>     	http://myHostName:port/myContextPath/myRequest/?myRequestParameters

The components of this URL are defined as follows:

  `myHostName`

  The DNS name mapped to the Web Server defined in the WebLogic Server Administration Console.

  This portion of the URL can be replaced with `host:port`, where `host` is the name of the machine running WebLogic Server and `port` is the port at which WebLogic Server is listening for requests.

  `port`

  The port at which WebLogic Server is listening for requests. The Servlet can communicate with the proxy only through the listenPort on the Server mBean and the SSL mBean.

  `myContextPath`

  The name of the context root which is specified in the weblogic.xml file, or the uri of the web module which is specified in the config.xml file.

  `myRequest`

  The name of the servlet as defined in the `web.xml` file.

  `myRequestParameters`

  Optional HTTP request parameters encoded in the URL, which can be read by an HTTP servlet.

## URL Pattern Matching

WebLogic Server provides the user with the ability to implement a URL matching utility which does not conform to the J2EE rules for matching. The utility must be configured in the weblogic.xml deployment descriptor rather than the web.xml deployment descriptor used for the configuration of the default implementation of URLMatchMap.

To be used with WebLogic Server, the URL matching utility must implement the following interface:

`Package weblogic.servlet.utils;`

`public interface URLMapping {`

`public void put(String pattern, Object value);`

`public Object get(String uri);`

`public void remove(String pattern)`

`public void setDefault(Object defaultObject);`

`public Object getDefault();`

`public void setCaseInsensitive(boolean ci);`

`public boolean isCaseInsensitive();`

public int size();

public Object[] values();

public String[] keys();

}

The SimpleApacheURLMatchMap Utility

The included SimpleApacheURLMatchMap utility is not J2EE specific. It can be configured in the weblogic.xml deployment descriptor file and allows the user to specify Apache style pattern matching rather than the default URL pattern matching provided in the web.xml deployment descriptor.

# Servlet Security

Security for servlets is defined in the context of the Web Application containing the servlet. Security can be handled by WebLogic Server, or it can be incorporated programmatically into your servlet classes.

For more information see Securing WebLogic Resourcessecwlres/index.html.

## Authentication

You can incorporate user authentication into your servlets using any of the following three techniques:

- BASIC—Uses the browser to collect a username and password.
- FORM—Uses HTML forms to collect a username and password.
- Client Certificate—Uses digital certificates to authenticate the user. For more information, see Digital Certificates".

The BASIC and FORM techniques call into a security role that contains user and password information. You can use a default role provided with WebLogic Server, or a variety of existing roles, including roles for Windows NT, UNIX, RDBMS, and user-defined roles. For more information about security roles, see Security Fundamentals.

## Authorization (Security Constraints)

You can restrict access to servlets and other resources in a Web Application by using security constraints. Security constraints are defined in the Web Application deployment descriptor (`web.xml`). There are three basic types of security constraints:

- Constraining resources by roles and/or resource
- Secure Sockets Layer (SSL) encryption
- Programmatic authorization

Roles can be mapped to a principal. Specific resources can be constrained by matching a URL pattern to a resource in a Web Application. You can also use Secure Sockets Layer (SSL) as a security constraint.

You can perform authorization programmatically, using one of the following methods of the `HttpServletRequest` interface:

- `getRemoteUser()`
- `isUserInRole()`
- `getUserPrincipal()`

For more information see the javax.servlet API.

# Servlet Development Tips

Consider the following tips when writing HTTP servlets:

- Compile your servlet classes into the `WEB-INF/classes` directory of your Web Application.
- Make sure your servlet is registered in the Web Applications deployment descriptor (`web.xml`).
- When responding to a request for a servlet, WebLogic Server checks the time stamp of the servlet class file prior to applying any filters associated with the servlet, and compares it to the servlet instance in memory. If a newer version of the servlet class is found, WebLogic Server re-loads all servlet classes before any filtering takes place. When the servlets are re-loaded, the `init()` method of the servlet is called. All servlets are reloaded when a modified servlet class is discovered due to the possibility that there are interdependencies among the servlet classes.

You can set the interval (in seconds) at which WebLogic Server checks the time stamp with the `Servlet Reload` attribute. This attribute is set on the `Descriptor` tab of your Web Application, in the Administration Console. If you set this attribute to zero, WebLogic Server checks the time stamp on every request, which can be useful while developing and testing servlets but is needlessly time consuming in a production environment. If this attribute is set to `-1`, WebLogic Server does not check for modified servlets.

# Clustering Servlets

Clustering servlets provides failover and load balancing benefits. To deploy a servlet in a WebLogic Server cluster, deploy the Web Application containing the servlet on all servers in the cluster. For instructions, see Deploying Applications to a Cluster in Using WebLogic Server Clusters.

For information on requirements for clustering servlets, and to understand the connection and failover processes for requests that are routed to clustered servlets, see Replication and Failover for Servlets and JSPs in Using WebLogic Server Clusters.

Note: Automatic failover for servlets requires that the servlet session state be replicated in memory. For instructions, see Configure In-Memory HTTP Replication in Using WebLogic Server Clusters.

For information on the load balancing support that a WebLogic Server cluster provides for servlets, and for related planning and configuration considerations for architects and administrators, see Load Balancing for Servlets and JSPs in Using WebLogic Server Clusters.