Configuring WebLogic Server Environments
The following sections describe how to configure a J2EE Web Application hosted on WebLogic Server to function as a standard HTTP Web Server hosting static content. Web Applications also can host dynamic content such as JSPs and Servlets. See Developing Web Applications, Servlets, and JSPs for WebLogic Server.
In addition to hosting dynamic Java-based distributed applications, WebLogic Server functions as a Web server that handles high-volume Web sites, serving static files such as HTML files and image files, as well as servlets and JavaServer Pages (JSP). WebLogic Server supports the HTTP 1.1 standard.
You can specify the port that each WebLogic Server listens on for HTTP requests. Although you can specify any valid port number, if you specify port
80, you can omit the port number from the HTTP request used to access resources over HTTP. For example, if you define port
80 as the listen port, you can use the form
http://hostname/myfile.html instead of
On UNIX systems, binding a process to a port lower than 1025 must be done from the account of a privileged user, usually root. Consequently, if you want WebLogic Server to listen on port 80, you must start WebLogic Server as a privileged user; yet it is undesirable from a security standpoint to allow long-running processes like WebLogic Server to run with more privileges than necessary. WebLogic needs root privileges only until the port is bound.
By setting the weblogic.system.enableSetUID property (and, if desired, the weblogic.system.enableSetGID property) to true, you enable an internal process by which WebLogic Server switches its UNIX user ID (UID) after it binds to port 80. The companion properties, weblogic.system.nonPrivUser and weblogic.system.nonPrivGroup, identify a non-privileged UNIX user account (and optionally a groupname) under which WebLogic Server will run after startup.
You can switch to the UNIX account "nobody," which is the least privileged user on most UNIX systems. If desired, you may create a UNIX user account expressly for running WebLogic Server. Make sure that files needed by WebLogic Server, such as log files and the WebLogic classes, are accessible by the non-privileged user. Once ownership of the WebLogic process has switched to the non-privileged user, WebLogic will have the same read, write, and execute permissions as the non-privileged user.
You define a separate listen port for non-SSL and secure (using SSL) requests. For additional information on configuring Listen Ports, see Understanding Network Channels.
HTTP and Web Applications are deployed according to the Servlet 2.4 and JSP 2.0 specifications from Sun Microsystems, which describe Web Applications as a standard for grouping the components of a Web-based application. These components include JSP pages, HTTP servlets, and static resources such as HTML pages or image files. In addition, a Web Application can access external resources such as EJBs and JSP tag libraries. Each server can host any number of Web Applications. You normally use the name of the Web Application as part of the URI you use to request resources from the Web Application.
For more information, see Developing Web Applications, Servlets, and JSPs for WebLogic Server.
Web Applications can be deployed to a WebLogic Server cluster. When a user requests a resource from a Web Application, the request is routed to one of the servers in the cluster that host the Web Application. If an application uses a session object, then sessions must be replicated across the nodes of the cluster. Several methods of replicating sessions are provided.
For more information, see Using WebLogic Server Clusters.
Every server instance and virtual host in your domain can declare a default Web Application. The default Web Application responds to any HTTP request that cannot be resolved to another deployed Web Application. In contrast to all other Web Applications, the default Web Application does not use the Web Application name as part of the URI. Any Web Application targeted to a server or virtual host can be declared as the default Web Application. (Targeting a Web Application is discussed later in this section. For more information about virtual hosts, see Configuring Virtual Hosting).
The examples domain that is shipped with WebLogic Server has a default Web Application already configured. The default Web Application in this domain is named
DefaultWebApp and is located in the
applications directory of the domain.
Virtual hosting allows you to define host names that servers or clusters respond to. When you use virtual hosting you use DNS to specify one or more host names that map to the IP address of a WebLogic Server instance or cluster, and you specify which Web Applications are served by the virtual host. When used in a cluster, load balancing allows the most efficient use of your hardware, even if one of the DNS host names processes more requests than the others.
For example, you can specify that a Web Application called
books responds to requests for the virtual host name
www.books.com, and that these requests are targeted to WebLogic Servers A,B and C, while a Web Application called
cars responds to the virtual host name
www.autos.com and these requests are targeted to WebLogic Servers D and E. You can configure a variety of combinations of virtual host, WebLogic Server instances, clusters, and Web Applications, depending on your application and Web server requirements.
For each virtual host that you define you can also separately define HTTP parameters and HTTP access logs. The HTTP parameters and access logs set for a virtual host override those set for a server. You may specify any number of virtual hosts.
You can also designate a default Web Application for each virtual host. The default Web Application for a virtual host responds to all requests that cannot be resolved to other Web Applications deployed on the same server or cluster as the virtual host.
Unlike other Web Applications, a default Web Application does not use the Web Application name (also called the context path) as part of the URI used to access resources in the default Web Application.
For example, if you defined virtual host name
www.mystore.com and targeted it to a server on which you deployed a Web Application called
shopping, you would access a JSP called
cart.jsp from the
shopping Web Application with the following URI:
For more information, see How WebLogic Server Resolves HTTP Requests.
When using multiple Virtual Hosts with different default web applications, you can not use single sign-on, as each web application will overwrite the JSESSIONID cookies set by the previous web application. This will occur even if the CookieName, CookiePath, and CookieDomain are identical in each of the default web applications.
When WebLogic Server receives an HTTP request, it resolves the request by parsing the various parts of the URL and using that information to determine which Web Application and/or server should handle the request. Table 5-1 demonstrates various combinations of requests for Web Applications, virtual hosts, servlets, JSPs, and static files and the resulting response.
Note: If you package your Web Application as part of an Enterprise Application, you can provide an alternate name for a Web Application that is used to resolve requests to the Web Application. For more information, see Developing Web Applications, Servlets, and JSPs for WebLogic Server.
Table 5-1 provides some sample URLs and the file that is served by WebLogic Server. The Index Directories Checked column refers to the Index Directories attribute that controls whether or not a directory listing is served if no file is specifically requested.
There are additional considerations for servlet mappings. For more information, see Configuring Servlets.
For more information, see Configuring Servlets.
WebLogic Server can keep a log of all HTTP transactions in a text file, in either common log format or extended log format. Common log format is the default. Extended log format allows you to customize the information that is recorded. You can set the attributes that define the behavior of HTTP access logs for each server instance or for each virtual host that you define.
You can rotate the log file based on either the size of the file or after a specified amount of time has passed. When either criterion is met, the current access log file is closed and a new access log file is started. If you do not configure log rotation, the HTTP access log file grows indefinitely. You can configure the name of the access log file to include a time and date stamp that indicates when the file was rotated. If you do not configure a time stamp, each rotated file name includes a numeric portion that is incremented upon each rotation. Separate HTTP access logs are kept for each Virtual Host you have defined.
The default format for logged HTTP information is the common log format. This standard format follows the pattern:
WebLogic Server also supports extended log file format, version 1.0, an emerging standard defined by the draft specification from W3C. The current definitive reference is on the W3C Technical Reports and Publications page
The extended log format allows you to specify the type and order of information recorded about each HTTP communication. To enable this format, set the Format attribute on the HTTP tab in the Administration Console to
Extended. (See Creating Custom Field Identifiers).
You specify what information should be recorded in the log file with directives, included in the actual log file itself. A directive begins on a new line and starts with a # sign. If the log file does not exist, a new log file is created with default directives. However, if the log file already exists when the server starts, it must contain legal directives at the head of the file.
xxxx describes the data fields to be recorded. Field types are specified as either simple identifiers, or may take a prefix-identifier format, as defined in the W3C specification. Here is an example:
This identifier instructs the server to record the date and time of the transaction, the request method that the client used, and the URI of the request for each HTTP access. Each field is separated by white space, and each record is written to a new line, appended to the log file.
You can also create user-defined fields for inclusion in an HTTP access log file that uses the extended log format. To create a custom field you identify the field in the ELF log file using the
Fields directive and then you create a matching Java class that generates the desired output. You can create a separate Java class for each field, or the Java class can output multiple fields. For a sample of the Java source for such a class, see Java Class for Creating a Custom ELF Field.
For more information on the
Fields directive, see Creating the Fields Directive.
Fieldsdirective (for example
myCustomField). This class defines the information you want logged in your custom field. The Java class must implement the following interface:
HttpAccountingInfoobject to access HTTP request and response data that you can output in your custom field. Getter methods are provided to access this information. For a complete listing of these get methods, see Get Methods of the HttpAccountingInfo Object.
CLASSPATHstatement used to start WebLogic Server. You will probably need to modify the
CLASSPATHstatements in the scripts that you use to start WebLogic Server.
Note: When writing the Java class that defines your custom field, do not execute any code that is likely to slow down the system (For instance, accessing a DBMS or executing significant I/O or networking calls.) Remember, an HTTP access log file entry is created for every HTTP request.
Note: If you want to output more than one field, delimit the fields with a tab character. For more information on delimiting fields and other ELF formatting issues, see Extended Log Format.
The following methods return various data regarding the HTTP request. These methods are similar to various methods of
A Denial-of-Service attack is a malicious attempt to overload a server with phony requests. One common type of attack is to send huge amounts of data in an HTTP
POST method. You can set three attributes in WebLogic Server that help prevent this type of attack. These attributes are set in the Console, under Servers or Virtual Hosts. If you define these attributes for a virtual host, the values set for the virtual host override those set under Servers.
HTTP tunneling provides a way to simulate a stateful socket connection between WebLogic Server and a Java client when your only option is to use the HTTP protocol. It is generally used to tunnel through an HTTP port in a security firewall. HTTP is a stateless protocol, but WebLogic Server provides tunneling functionality to make the connection appear to be a regular T3Connection. However, you can expect some performance loss in comparison to a normal socket connection.
Under the HTTP protocol, a client may only make a request, and then accept a reply from a server. The server may not voluntarily communicate with the client, and the protocol is stateless, meaning that a continuous two-way connection is not possible.
WebLogic HTTP tunneling simulates a T3Connection via the HTTP protocol, overcoming these limitations. There are two attributes that you can configure in the Administration Console to tune a tunneled connection for performance. It is advised that you leave them at their default settings unless you experience connection problems. These properties are used by the server to determine whether the client connection is still valid, or whether the client is still alive.
When an HTTP tunnel connection is set up, the client automatically sends a request to the server, so that the server may volunteer a response to the client. The client may also include instructions in a request, but this behavior happens regardless of whether the client application needs to communicate with the server. If the server does not respond (as part of the application code) to the client request within the number of
If the number of
On the client side, a special tag is appended to the
http protocol, so that WebLogic Server knows this is a tunneling connection, instead of a regular HTTP request. Your application code does not need to do any extra work to make this happen.
The client must specify the port in the URL, even if the port is 80. You can set up your WebLogic Server instance to listen for HTTP requests on any port, although the most common choice is port 80 since requests to port 80 are customarily allowed through a firewall.
When running WebLogic Server on Windows NT/2000/XP you can specify that WebLogic Server use the native operating system call TransmitFile instead of using Java methods to serve static files such as HTML files, text files, and image files. Using native I/O can provide performance improvements when serving larger static files.
To use native I/O, add two parameters to the web.xml deployment descriptor of a Web Application containing the files to be served using native I/O. The first parameter, weblogic.http.nativeIOEnabled should be set to TRUE to enable native I/O file serving. The second parameter, weblogic.http.minimumNativeFileSize sets the minimum file size for using native I/O. If the file being served is larger than this value, native I/O is used. If you do not specify this parameter, a value of 4K is used.
Generally, native I/O provides greater performance gains when serving larger files; however, as the load on the machine running WebLogic Server increases, these gains diminish. You may need to experiment to find the correct value for weblogic.http.minimumNativeFileSize.
The following example shows the complete entries that should be added to the web.xml deployment descriptor. These entries must be placed in the web.xml file after the <distributable> element and before <servlet> element.