JSP 1.2 Errata - May 24th, 2002 (rev b)
Please send feedback to firstname.lastname@example.org .
The following is a list of clarifications and corrections to the JSP 1.2 final specification (dated August 27th, 2001). They build atop the existing Errata A, which closed on April 22, 2002.
This errata has been created according to the Maintenance step of the JCP process . Issues were prompted by questions from vendors, implementors and end-users; the resolutions have been discussed in a mailing list which includes all the experts in the JSP 1.3 expert group. The discussion was done under the facilitation of Mark Roth, co-lead of the JSP 1.3 specification, acting as "Maintenance Lead" for the JSP 1.2 specification. This errata includes all issues discussed up until May 24th, 2002.
This errata will be posted for a 30 day public review before being declared final.
All issues will be incorporated into the JSP 1.3 specification, which, at the time of this writing, is currently being developed under JSR-152 of the JCP. It is still undecided if there will be additional erratas or if later clarifications will be just appear in the JSP 1.3 specification.
The errata starts with a brief list of all issues. Each issue is then described in more detail and a resolution is given. All references are to the JSP 1.2 final specification (with changes in Errata_a incorporated).
All Issues1. Standard Actions: Translation-time checking for bean tags
Standard Actions: Translation-time checking for bean tags
Sections JSP.4.1 and JSP.4.3 of the JSP 1.2 specification need to be clarified.
Specifically, the <jsp:useBean> standard action has both "class" and "type" attributes. A page that passes, to the "class" attribute of the <jsp:useBean> standard action, the name of an abstract class, interface, or a class with no public no-args constructor, is in violation of the spec. This is what the "type" attribute is for. Therefore, to improve developer experience and catch this error nearest to its source, a container should be able to produce a translation error for pages that attempt this.
Additionally, for the <jsp:getProperty> and <jsp:setProperty> standard actions, the specification currently states that an object must have been "introduced" to the container, but does not specify what the container can do if they were not.
Both of these clarifications are intended to allow containers to produce higher quality errors for pages that are in violation of the specification, as to enhance application portability.
JSP.4.1. <jsp:useBean>[The following paragraph replaces the second item 1 on page 70 of the JSP 1.2 specification (items changed/added in bold)]
1. An attempt to locate an object based on the attribute values id and scope. The inspection is done synchronized per scope namespace to avoid non-deterministic behavior.
1a. A scripting language variable of the specified type (based on the "type" attribute, if given, or the "class" attribute if not) is defined with the given id in the current lexical scope of the scripting language. The "type" attribute should be used to specify a Java type that cannot be instantiated as a JavaBean (i.e. a Java type that is an abstract class, interface, or a class with no public no-args constructor). If the "class" attribute is used for a Java type that cannot be instantiated as a JavaBean, the container may consider the page invalid, and is recommended to (but not required to) produce a fatal translation error at translation time, or a java.lang.InstantiationException at request time. Similarly, if either "type" or "class" specify a type that can not be found, the container may consider the page invalid, and is recommended to (but not required to) produce a fatal translation error at translation time, or a java.lang.ClassNotFoundException at request time.
2. If the object is found, ...
JSP.4.3. <jsp:getProperty>[The following paragraph replaces the fifth paragraph of section JSP.4.3 of the JSP 1.2 specification (items changed/added in bold)]
The object named by the name must have been "introduced" to the JSP processor using either the jsp:useBean action or a custom action with an associated VariableInfo entry for this name. If the object was not "introduced" in this manner, the container implementation is recommended (but not required) to raise a translation error, since the page implementation is in violation of the specification.