JSP 1.2 Errata - May 24th, 2002 (rev b)
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 Issues
1. Standard Actions: Translation-time checking for bean tags
Issue 1
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.
Resolution
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.
...
