 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 152: JavaServer PagesTM 2.0 Specification
JCP version in use: 2.1 Java Specification Participation Agreement version in use: 1.0 Description: Next revision of the JavaServer PagesTM specification. Please direct comments on this JSR to the Spec Lead(s) Team
Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Sun Microsystems, Inc. Name of Contact Person: Eduardo Pelegri-Llopart E-Mail Address: Eduardo.Pelegrillopart@Sun.COM Telephone Number: +1 408 276 7234 Fax Number: +1 408 276 7191 Specification Lead: Eduardo Pelegri-Llopart & Mark Roth E-Mail Address: Eduardo.Pelegrillopart@Sun.COM & Mark.Roth@Sun.COM Telephone Number: +1 408 276 7234 & +1 781 442 2229 Fax Number: +1 408 276 7191 & 781 442 1610 Supporting this JSR: ATG Several individuals that have participated in previous JSP EG have already indicated their intention to participate in this EG: Hans Bergsten, Kevin Jones, Rickard Oberg, James Strachan We expect additional JCP participants and individuals (IEPA) to participate in this EG. Section 2: Request
2.1 Please describe the proposed Specification:The use of products based on the JavaServer Pages(tm) (JSP) specification in the Java community continues to grow. The users include:
- Containers This wealth of feedback and ideas provides direct input into what parts of the JSP specification are most beneficial, which parts need improvement and which features are missing. This JSR requests the creation of an expert group (EG) to drive the next version of the JavaServer Pages(tm) specification using this input, as well as accumulated expertise from the Expert Groups that worked in the previous versions of JSP. We plan to incorporate two main new features into JSP, and a few incremental features. Additionally we expect to incorporate erratas and clarifications as well as oportunistic improvements. The two key features are the use of JSP to author custom actions, and adding expression language support into the container. The main goal of this JSR is to deliver these new features into the JSP specification in a timely manner. This goal will likely limit what other features can be incorporated. * Use of JSP to author custom actions JSP 1.2 has several mechanisms for providing a reusable abstraction: static include directives, dynamic include actions and custom actions. Of these, custom actions are the most flexible ones, but they need to be written in Java, which means that a page author must request the help of a Java developer. Furthermore, writing a custom action that uses other custom actions is quite error-prone. It would be very valuable to add a mechanism that would allow a page author to easily abstract a JSP fragment into a new custom action that later can instantiated and used. A number of participants in the JSP community have proprietary mechanisms that provide this type of functionality. We would like to build on this expertise to deliver a mechanism that could be used for this. * Expression Language support in container A common usage pattern for JSP pages involves abstracting away all computation in the JSP page into custom actions or JavaBean components, instantiated or invoked within the JSP page, or in actions that happen before the JSP page is invoked. In these pattern, the computation that still needs to be described within the page can be characterized as expression evaluation. In JSP 1.2, these expressions must be described using Java expressions, even when in many cases the JSP page author thinks of the expression as operating on JavaBeans objects. Also, recently we have started seeing uses where the key abstraction is that of XML nodes. The JavaServer Pages standard Tag Library (JSPTL) is being developed in the Java Community Process as JSR-052. The JSPTL EG has reacted to this use pattern by adding support for a 'simple expression language' in the current drafts of the specification. This expression language support is limited to the custom actions in JSPTL and cannot be used in any other custom tag library without changes to the code of the library. The simple expression language approach has been explored in a number of different forums, including ECMAScript, other JSP tag libraries, some servlet-based but non-JSP-based projects and some non-Java based projects. We would like to incorporate support for an expression language at the container level in the next revision of the JSP specification. This would make the expression language available when using any existing custom action, and would enable the container to perform optimizations on the expressions. * Additional Community Feedback We want to incorporate feedback from a number of different ongoing efforts:
- JSPTL Two specific areas that we would like to improve are: * Improve localization; in particular, JSP 1.2 has some problems with identifying some encoding of the JSP pages. * Improve page authoring support; in particular, the Tag Library Descriptor file is still missing some useful information. Finally, if the request for a Servlet 2.4 specification is granted, we will use it. * One theme: simplified use One main theme of this update of the JSP specification is that we want to simplify, not complicate, the view of a JSP that most users, specially page authors, have. This while the full power and flexibility of JSP is available for those projects when it is appropriate. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)J2EE 1.4 2.3 What need of the Java community will be addressed by the proposed specification?See 2.1 above 2.4 Why isn't this need met by existing specifications?See 2.1 above 2.5 Please give a short description of the underlying technology or technologies:See 2.1 above 2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.jsp.*, javax.jsp.tagext.* 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?The JSP specification will build on the Servlet 2.4 specification in this area. 2.9 Are there any internationalization or localization issues?See 2.1 above 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.The specification will follow the J2EE 1.4 schedule. 2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.We envision an elaboration of the style followed in the JSR-053 EG: an active Expert Group, with an open mailing list that is combined with private communication and with a EG web site for exchanging of information. There was a recent article on JSR-053 at the JCP web site; the article is mostly quite reasanable, and is available at http://www.jcp.org/resources/guide/jsr53.jsp. 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.* J2EE 1.3, JSP 1.2, Servlet 2.3 These are the basic J2EE 1.3 specifications, now final and available at: http://java.sun.com/j2ee/docs.html#specs * JSPTL, the JSP Standard Tag Library JSPTL is still being worked. It addresses key issues of usability by JSP page authors, including an expression language. http://www.jcp.org/jsr/detail/52.jsp and http://jakarta.apache.org/taglibs/doc/jsptl-doc/intro.html * JavaServer Faces, JSF This specification effort is in the early stages. http://www.jcp.org/jsr/detail/127.jsp * Draft JSR for J2EE 1.4 The umbrella JSR for J2EE 1.4. URL yet to be assigned by the JCP. * Draft JSR for Servlet 2.4 The JSR for the base servlet functionality that we expect JSP 1.3 to use. URL yet to be assigned by the JCP. * ECMAScript ECMAscript is a popular scripting language. A subset of ECMAscript is being considered by the JSPTL EG as a simple expression language. http://www.ecma.ch/ecma1/stand/ecma-262.htm * XPATH, the XML Path Language XPath is a language for addressing parts of an XML document, designed to be used by both XSLT and XPointer. XPath is being consired by the JSPTL EG for some XML-aware tags. * Dynamo Server Pages, DSP DSP is a popular language for dynamic generation of web content. It includes some ideas that can be used to provide author-level programmability of abstractions. ATG is an initial member of this EG and we expect to draw on the experience gained with DSP to provide JSP page authors the ability to write custom actions. * JRun Server Tags, JST JST is a mechanism present in Macromedia's JRun that permits authoring of JSP custom actions by JSP page authors. Macromedia is an initial member of this EG and we expect to draw on the experience gained with JST to provide JSP page authors the ability to write custom actions. 3.2 Explanation of how these items might be used as a starting point for the work.See 3.1 above. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
