Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Developer's Guide

- Previous: Part I Developing and Deploying Applications
- Next: Using Servlets

# Introducing Web Applications

This section includes summaries of the following topics:

- Internationalization Issues

- Virtual Servers

- Default Web Modules

- Classloader Delegation

- Using the default-web.xml File

- Configuring Logging in the Web Container

- Configuring Idempotent URL Requests

- Configuring HTML Error Pages

- Header Management

- Redirecting URLs

## Internationalization Issues

This section covers internationalization as it applies to the following:

- The Server

- Servlets

### The Server

To set the default locale of the entire Application Server, which determines the locale of the Administration Console, the logs, and so on, use the Administration Console. Select the Domain component, and type a value in the Locale field. For details, see the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Guide.

### Servlets

This section explains how the Application Server determines the character encoding for the servlet request and the servlet response. For encodings you can use, see `http://java.sun.com/j2se/1.4/docs/guide/intl/encoding.doc.html`.

#### Servlet Request

When processing a servlet request, the server uses the following order of precedence, first to last, to determine the request character encoding:

- The ```getCharacterEncoding()` method.

- A hidden field in the form, specified by the `form-hint-field` attribute of the `parameter-encoding` element in the `sun-web.xml` file.

- The character encoding set in the `default-charset` attribute of the `parameter-encoding` element in the `sun-web.xml` file.

- The default, which is `ISO-8859-1`.

For details about the `parameter-encoding` element, see parameter-encoding.

#### Servlet Response

When processing a servlet response, the server uses the following order of precedence, first to last, to determine the response character encoding:

- The `setCharacterEncoding()` or ```setContentType()` method.

- The ```setLocale()` method.

- The default, which is `ISO-8859-1`.

## Virtual Servers

A virtual server, also called a virtual host, is a virtual web server that serves content targeted for a specific URL. Multiple virtual servers can serve content using the same or different host names, port numbers, or IP addresses. The HTTP service directs incoming web requests to different virtual servers based on the URL.

When you first install the Application Server, a default virtual server is created. (You can also assign a default virtual server to each new HTTP listener you create. For details, see the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Guide.)

Web applications and J2EE applications containing web components can be assigned to virtual servers.

### To assign virtual servers

1. Deploy the application or web module and assign the desired virtual server to it.

   For more information, see Tools for Deployment.

2. In the Administration Console, open the HTTP Service component under the relevant configuration.

3. Open the Virtual Servers component under the HTTP Service component.

4. Select the virtual server to which you want to assign a default web module.

5. Select the application or web module from the Default Web Module drop-down list.

   For more information, see Default Web Modules.

##### See Also

For details, see the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Guide.

## Default Web Modules

A default web module can be assigned to the default virtual server and to each new virtual server. For details, see Virtual Servers. To access the default web module for a virtual server, point the browser to the URL for the virtual server, but do not supply a context root. For example:

    http://myvserver:3184/

A virtual server with no default web module assigned serves HTML or JSP content from its document root, which is usually domain-dir`/docroot`. To access this HTML or JSP content, point your browser to the URL for the virtual server, do not supply a context root, but specify the target file.

For example:

    http://myvserver:3184/hellothere.jsp

## Classloader Delegation

The Servlet specification recommends that the Web Classloader look in the local class loader before delegating to its parent. To make the Web Classloader follow the delegation model in the Servlet specification, set `delegate="false"` in the `class-loader` element of the `sun-web.xml` file. It’s safe to do this only for a web module that does not interact with any other modules.

The default value is `delegate="true"`, which causes the Web Classloader to delegate in the same manner as the other classloaders. Use `delegate="true"` for a web application that accesses EJB components or that acts as a web service client or endpoint. For details about `sun-web.xml`, see The sun-web.xml File.

For general information about classloaders, see Classloaders.

## Using the default-web.xml File

You can use the `default-web.xml` file to define features such as filters and security constraints that apply to all web applications.

### To use the default-web.xml file

1. Place the JAR file for the filter, security constraint, or other feature in the domain-dir`/lib` directory.

2. Edit the domain-dir`/config/default-web.xml` file to refer to the JAR file.

3. Restart the server.

##### The InvokerServlet

The `InvokerServlet` allows use of the `servlet-name` instead of the `servlet-mapping` for invoking a servlet with a URL, as described in Invoking a Servlet with a URL. The `InvokerServlet` is commented out in the `default-web.xml` file. To re-enable the `InvokerServlet`, remove the comment indicators (`<!--` and `-->`), then restart the server.

## Configuring Logging in the Web Container

For information about configuring logging and monitoring in the web container using the Administration Console, see the Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Guide.

## Configuring Idempotent URL Requests

An idempotent request is one that does not cause any change or inconsistency in an application when retried. To enhance the availability of your applications deployed on an Application Server cluster, configure the load balancer to retry failed idempotent HTTP requests on all the Application Server instances in a cluster. This option can be used for read-only requests, for example, to retry a search request.

This section describes the following topics:

- Specifying an Idempotent URL

- Characteristics of an Idempotent URL

### Specifying an Idempotent URL

To configure idempotent URL response, specify the URLs that can be safely retried in idempotent-url-pattern elements in the `sun-web.xml` file. For example:

    <idempotent-url-pattern url-pattern="sun_java/*" no-of-retries="10"/>

For details, see idempotent-url-pattern.

If none of the server instances can successfully serve the request, an error page is returned. To configure custom error pages, see Configuring HTML Error Pages.

### Characteristics of an Idempotent URL

Since all requests for a given session are sent to the same application server instance, and if that Application Server instance is unreachable, the load balancer returns an error message. Normally, the request is not retried on another Application Server instance. However, if the URL pattern matches that specified in the `sun-web.xml` file, the request is implicitly retried on another Application Server instance in the cluster.

In HTTP, some methods (such as GET) are idempotent, while other methods (such as POST) are not. In effect, retrying an idempotent URL should not cause values to change on the server or in the database. The only difference should be a change in the response received by the user.

Examples of idempotent requests include search engine queries and database queries. The underlying principle is that the retry does not cause an update or modification of data.

A search engine, for example, sends HTTP requests with the same URL pattern to the load balancer. Specifying the URL pattern of the search request to the load balancer ensures that HTTP requests with the specified URL pattern is implicitly retried on another Application Server instance.

For example, if the request URL sent to the Application Server is of the type `/search/`something`.html`, then the URL pattern can be specified as `/search/*`.

Examples of non-idempotent requests include banking transactions and online shopping. If you retry such requests, money might be transferred twice from your account.

## Configuring HTML Error Pages

To specify an error page (or URL to an error page) to be displayed to the end user, use the `error-url` attribute of the sun-web-app element in the `sun-web.xml` file. For example:

    <sun-web-app error-url="webserver-install-dir/error/error1.html">
    ... subelements ...
    </sun-web-app>

For details, see sun-web-app.

If the `error-url` attribute is specified, it overrides all other mechanisms configured for error reporting.

Note –

This attribute should not point to a URL on the Application Server instance, because the `error-url` cannot be loaded if the server is down. Instead, specify a URL that points to a location on the web server.

The Application Server provides the following options for specifying the error page.

- You can specify the `error-url` to be an HTTP URL. The Application Server forwards the client request to the specified error URL.

- You can specify the `error-url` to be the name of an HTML page in the standard load balancer plug-in’s error pages directory. Do not specify an absolute path in the local file system. The location must be relative to the webserver-install-dir`/plugins/lbplugin/``errorpages` directory.

- If you do not specify the `error-url` attribute in the `sun-web.xml` file, a default error page , `sun-http-lberror.html`, from the standard error pages directory, `errorpages`, is displayed if present.

  As part of the load balancer plug-in installation, a directory called `errorpages` is created in the web server installation directory.

The error page is displayed according to the following rules:

- When an error is encountered for an application, the Application Server first checks if the `error-url` attribute is defined. If it is defined, the Application Server reads the URL attribute and loads the error page.

- If the `error-url` attribute is missing or invalid, the Application Server displays the default error page, `sun-http-lb-error.html`, from the `errorpages` directory of the load balancer plug-in.

- If the `error-url` has been defined but the page is missing, the Application Server loads the default error page, `sun-http-lb-error.html`.

- If the default error page is missing, the error is forwarded to the web server.

## Header Management

In the Platform Edition of the Application Server, the `Enumeration` from `request.``getHeaders()` contains multiple elements. In the Enterprise Edition, this `Enumeration` contains a single, aggregated value.

The header names used in `HttpServletResponse.add` XXX `Header()` and `HttpServletResponse.set` XXX `Header()` are returned differently to the HTTP client from the Platform Edition and the Enterprise Edition of the Application Server. The Platform Edition preserves the names as they were created. The Enterprise Edition capitalizes the first letter but converts all other letters to lower case. For example, if `sampleHeaderName2` is used in `response.addHeader()`, the response name in the Platform Edition is unchanged, but the response name in the Enterprise Edition is `Sampleheadername2`.

## Redirecting URLs

You can specify that a request for an old URL is treated as a request for a new URL. This is called redirecting a URL.

To specify a redirected URL for a virtual server, use the `redireect_`n property, where n is a positive integer that allows specification of more than one. This property is a subelement of a `virtual-server` element in the `domain.xml` file. For more information about this element, see `virtual-server` in Sun Java System Application Server Enterprise Edition 8.1 2005Q2 Administration Reference. Each of these `redirect_`n properties is inherited by all web applications deployed on the virtual server.

The value of each `redirect_`n property has two components, which may be specified in any order:

The first component, `from`, specifies the prefix of the requested URI to match.

The second component, `url-prefix`, specifies the new URL prefix to return to the client. The `from` prefix is simply replaced by this URL prefix.

For example:

    <property name="redirect_1" value="from=/dummy url-prefix=http://etude"/>

- Previous: Part I Developing and Deploying Applications
- Next: Using Servlets

- © 2010, Oracle Corporation and/or its affiliates