Filters and Servlet Chaining

Contents / New Features / Administrator Docs / Developer Docs / Index / Servlet Features

Filters and Servlet Chaining

In the Java^TM Web Server^TM, filtering support is provided by the ability to flexibly chain servlets. Both local and remote servlets can be part of the chain. Filtering is yet another way to load and invoke servlets in the Java Web Server. The sections below describe servlet chaining in more detail.

For information on how to setup servlet chaining using the Administration Tool, see Servlet Aliases.

Enabling Filters and Servlet Chaining

In the basic subsection of the setup section, there is a button to indicate whether servlet chaining is enabled. By default, this is disabled - set the button to enable if you want to enable servlet chaining and filtering capabilities in your server.

Servlet Chains

For some requests, a chain of ordered servlets can be invoked rather than just one servlet. The input from the browser is sent to the first servlet in the chain and the output from the last servlet in the chain is the response sent back to the browser. Each servlet in the chain has the inputs and outputs piped to the servlet before and after it, respectively. A chain of servlets can be triggered for an incoming request by:

Using Servlet Aliasing to indicate a chain of servlets for a request.
Using MIME types to trigger the next servlet in the chain.

Each of the above two are explained in more detail below.

How to Configure a Servlet Chain Using Servlet Aliasing

Using the Servlet Aliasing subsection of the setup section in the Administration Tool, a list of servlets can be named for a particular URL request. In the servlets table, when adding a new mapping, you are allowed to enter a comma-separated list of servlets in the order in which they should be invoked when a request arrives for that particular URL. This configures a servlet chain to be invoked every time a request that matches the URL arrives.

MIME Types and Servlets

The Java Web Server provides a great deal of flexibility in how servlets can be invoked. One way of invoking servlets is by associating a servlet with a particular mime-type such that the servlet so configured is invoked each time a response with the corresponding mime-type is generated.

When a servlet writes to the OutputStream for the first time, the mime-type is checked. If there is a servlet configured for this particular mime-type, then the OutputStream of the response is piped to the InputStream of the servlet. Thus, the second servlet's request stream is essentially a pipe from the first servlet's response stream. In this way, many such servlets can be chained together.

How to Configure a Servlet Chain Using MIME Types

There is no Administrative Tool support for servlet chaining. The administrator will need to to manually edit the mimeservlets.properties file. This file resides in the directory
<server_root>/properties/server/javawebserver/webpageservice/

This file maps MIME types to servlet names. Servlet names are mapped to actual classes using the servlets section of the Administrative Tool. This flexible approach means that some of the servlets in the servlet chain can actually be configured to be remote servlets. In the case of remote servlets in the chain, they are brought over before being invoked.

Triggering Filter Chains

When servlets generate responses, they set the MIME type of the response. When a particular MIME type is configured to invoke another servlet in the mimeservlets.properties file, the filter chain is triggered. For servlets that get invoked in the chain, their request inputs are the outputs of the previous member in the chain.

Security in Servlet Chains

All servlets in a servlet chain are subjected to the same security constraints when it comes to ACL-based protection. Two servlets cannot be protected by two different ACLs and belong in the same chain, since the request is from a single client. If they are configured to be protected by two different ACLs, then a response will not be generated.

Also, if a particular servlet is protected using an ACL in the chain, then the entire chain becomes protected. That is, if the third servlet in a chain is protected and the first two are not, then a response is not generated unless a valid user/password is entered before the chain is invoked.

Servlet sandboxes are preserved as usual for individual servlets. Individual servlets can be sandboxed if they are remote and they behave exactly as if they had not been in a servlet chain.

Top

java-server-feedback@java.sun.com