Administration and Configuration

 

This section provides a brief overview of administration and configuration tasks for WebLogic HTTP servlets. For a complete discussion of servlet administration and configuration see "Using WebLogic Server HTTP/Web Services" in the WebLogic Server Administration Guide.

This section discusses the following topics:

• Overview

• URL

• Directory Structure

• Security

• Servlet Development Tips

• Clustering Servlets

Overview

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.2 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 web.xml file see "Writing Web Application 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

• 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: "WebApp Component"

• Administration Console: " Virtual Hosts"

Directory Structure

Use the following directory structure for all Web Applications:

WebApplicationRoot/(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

URL

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

myContextPath

the name of the Web Application defined in the WebLogic Server Administration Console

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.

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 "Configuring Security in Web Applications".

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 realm that contains user and password information. You can use a default realm provided with WebLogic Server, or a variety of existing realms, including realms for Windows NT, UNIX, RDBMS, and user-defined realms. For more information about security realms, 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 theWeb Application deployment descriptor (web.xml). Resources may be constrained by roles and/or by resource. Roles can be mapped to a principal in a realm. Specific resources can be constrained by matching a URL pattern to a resource in a Web Application. Finally, the use of Secure Sockets Layer (SSL) can be specified for a security constraint.

You can also 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:

• Make sure you 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 and compares it to the servlet instance in memory. If a newer version of the servlet class is found, WebLogic Server re-loads the servlet class. When a servlet is re-loaded, the init() method of the servlet is called.

  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 Files 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

To deploy an HTTP servlet in a cluster of WebLogic Servers, deploy the Web Application containing the servlet on all of the servers in the cluster. Depending on the cluster configuration, requests are routed to various servers in the cluster, each of which has access to a copy of the Web Application resources.

For more information on clustering, see Using WebLogic Server Clusters .