![]() |
![]() |
|
|
| |
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
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:
For a complete discussion of creating the 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:
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:
For more information see the following resources:
Directory Structure for Web Applications
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
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:
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".
You can incorporate user authentication into your servlets using any of the following three techniques:
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). There are three basic types of security constraints:
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. 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:
For more information see the javax.servlet API.
Consider the following tips when writing HTTP servlets:
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 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 "Deploy Web Applications and EJBs" in Using WebLogic Server Clusters.
For information on failover for clustered servlets, see "Failover Support for Clustered Services" and "Understanding HTTP Session State Replication" in Using WebLogic Server Clusters.
Note: Automatic failover for servlets requires that the servlet session state be replicated in memory. For instructions, see "Configuring In-Memory HTTP Replication in a Cluster" 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 HTTP Session States" in Using WebLogic Server Clusters.
![]() |
![]() |
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|