Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 154: JavaTM Servlet 2.4 Specification

Stage Access Start Finish
Maintenance Release 2 Download page 11 Sep, 2007  
Maintenance Draft Review 6 Download page 04 Oct, 2006 06 Nov, 2006
Maintenance Release Download page 11 May, 2006  
Maintenance Draft Review 5 Download page 31 Mar, 2006 01 May, 2006
Maintenance Draft Review 4 Download page 14 Feb, 2006 20 Mar, 2006
Maintenance Draft Review 3 Download page 25 Aug, 2005 26 Sep, 2005
Maintenance Draft Review 2 Download page 06 May, 2004 07 Jun, 2004
Maintenance Draft Review Download page 26 Feb, 2004 29 Mar, 2004
Final Release Download page 24 Nov, 2003  
Final Approval Ballot View results 28 Oct, 2003 11 Nov, 2003
Proposed Final Draft 3 Download page 17 Apr, 2003  
Proposed Final Draft 2 Download page 06 Mar, 2003  
Proposed Final Draft Download page 08 Aug, 2002  
Public Review Download page 26 Jun, 2002 26 Jul, 2002
Community Draft Ballot View results 11 Jun, 2002 17 Jun, 2002
Community Review Login page 14 May, 2002 17 Jun, 2002
Expert Group Formation   23 Oct, 2001  
JSR Review Ballot View results 09 Oct, 2001 22 Oct, 2001
Status: Maintenance
JCP version in use: 2.6
Java Specification Participation Agreement version in use: 2.0


Description:
This specification will build on servlet specification version 2.3 by enhancing existing features and adding new facilities of a reasonably small nature.

Please direct comments on this JSR to the Spec Lead(s)
Team

Specification Leads
  Rajiv Mordani Oracle
Expert Group
  Abramson, Nathan Apache Software Foundation Art Technology Group Inc.(ATG)
  Avedal, Karl BEA Systems Bergsten, Hans
  Boeing Borland Software Corporation Developmentor
  Hunter, Jason IBM InterX PLC
  Johnson, Rod Lutris Technologies New Atlanta Communications, LLC
  Novell, Inc. Oracle Persistence Software Inc.
  Pramati Technologies Progress Software SAS Institute Inc.
  Sun Microsystems, Inc. Sybase Wilkins, Greg

Updates to the Original JSR

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: -

2004.02.26

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:

BEA
IONA
Oracle



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