JSR 154: Java^TM Servlet 2.4 Specification

The following information has been updated from the original request.

2007.09.11:

Maintenance Lead: Rajiv Mordani

E-Mail Address: rajiv.mordani@sun.com

Telephone Number: +1 408 203 2674

Fax Number: -

Maintenance Lead: Gregory Murray

E-Mail Address: gregory.murray@sun.com

Telephone Number: -

Fax Number: -

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: Sun Microsystems, Inc.

Name of Contact Person: Danny Coward

E-Mail Address: Danny.Coward@sun.com

Telephone Number: +1 408 276 7049

Fax Number: +1 408 276 7191

Specification Lead: Danny Coward

E-Mail Address: Danny.Coward@sun.com

Telephone Number: +1 408 276 7049

Fax Number: +1 408 276 7191

Supporting this JSR:

Section 2: Request

2.1 Please describe the proposed Specification:

Servlet 2.4 will be a relatively small upgrade to the existing API. Since the technology is highly popular, we have a large number of small requests for enhancement to the API that we would like to be able to accommodate. Over and above that, Servlet 2.4 will address the following areas in a portable manner:-

* Modularization of the deployment format

The goal is to achieve a level of modularity with the deployment format which is not currently possible using the current DTD based deployment descriptor. The intent is to enable this modularity to manage the organization of deployment information of related technologies that use the web container as the underlying platform. These frameworks include dependencies on other J2EE components, JSP technology, JavaServer Faces, JAXM, JAX-RPC and other frameworks that build on servlet semantics. As usual with such a revision of a technology, web applications with deployment descriptors conforming to versions 2.2 and 2.3 of the specification will continue to be able to be deployed on Servlet 2.4 containers.

* Enhancements to the security model
- Provide a facility for logging out of web applications portably
- Clarify, possibly by adding API or deployment syntax, the relationship between HTTP session state and authentication state

* Smallish enhancements to the filter and listener models
- Provision of deployment syntax for declaring API dependencies between elements in a filter chain
- Addition of request and response level listeners and event notifications.

* Backwards compatible enhancements to the servlet API and semantics to enable containers to take advantage of the new J2SE IO package

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java 2 Enterprise Edition

2.3 What need of the Java community will be addressed by the proposed specification?

Since Java servlet technology is a mature technology we see a heavy use of the servlet model as a deployment vehicle for technologies that build on the web container. Some of those technologies are listed in 2.1. Modularizing the deployment format of web applications will further enable these technologies. The filter and listener component models that were introduced for the 2.3 revision of the specification have proved popular thus far, and we would like to continue to promote the model by enhancing the component model for each. The new J2SE IO package promises higher performance for servlet containers which we would like to capitalize on in the web container.

2.4 Why isn't this need met by existing specifications?

Since Java servlet technology is a mature technology we see a heavy use of the servlet model as a deployment vehicle for technologies that build on the web container. Some of those technologies are listed in 2.1. Modularizing the deployment format of web applications will further enable these technologies. The filter and listener component models that were introduced for the 2.3 revision of the specification have proved popular thus far, and we would like to continue to promote the model by enhancing the component model for each. The new J2SE IO package promises higher performance for servlet containers which we would like to capitalize on in the web container.

2.5 Please give a short description of the underlying technology or technologies:

We are making incremental enhancements to the existing Java servlet technology. This is described in the 2.3 version of the specification.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

We will continue to use javax.servlet.* and javax.servlet.http.*.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No

2.8 Are there any security issues that cannot be addressed by the current security model?

Security issues described above.

2.9 Are there any internationalization or localization issues?

We are not proposing significantly to enhance or alter the existing mechanisms for localization and internationalization.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No

2.11 Please describe the anticipated schedule for the development of this specification.

We expect this specification to be complete in the J2EE 1.4 timeframe.

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

We anticipate a mixture of mailing list and occasional face to face or teleconference meetings.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

We are building on the existing Java servlet 2.3 specification:
http://jcp.org/jsr/detail/53.jsp

3.2 Explanation of how these items might be used as a starting point for the work.

As an incremental upgrade to the technology, we will be building on the last revision, version 2.3.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

None