 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
JSR 315
Maintenance Release - Workspace The following are the proposed changes
to the servlet 3.0 (JSR 315) since its final release.
These changes have been discussed in the JSR mailing list with the expert group
members. 1. Version number of the document is changed to
3.0 Rev a. The API still remains at 3.0 2. Clarify that "location" attribute of javax.servlet.annotation.MultipartConfig
and the location element of <multipart-config>
is interpreted as an absolute path and defaults to the value of the "javax.servlet.context.tempdir". If a relative path is
specified, it will be relative to the tempdir
location. The test for absolute path vs relative path
must be done via java.io.File.isAbsolute 3. Update section 7.5 to be consistent with the javadocs and schema as follows � �This time out can be
changed by the Developer using the setMaxInactiveInterval
method of the HttpSession interface. The time out
periods used by these methods are defined in seconds. By definition, if the
time out period for a session is set to zero or lesser value, the session will
never expire. The session invalidation will not take effect until all servlets using that session have exited the service method.
Once the session invalidation is initiated, a new request must not be able to
see that session. 4.
Update Section 8.2.1 to say that a
�plain old jar file� in the WEB-INF/lib directory with no web-fragment.xml is
also considered a fragment. Any annotations specified in it will be processed
according to the rules defined in 8.2.3 5.
Add
the following text to Chapter 8 section 8.2.2 1. There can only be one
<absolute-ordering> element in the web.xml descriptor and there can only
be one <name> element in a descriptor (web.xml or web-fragment.xml). 2. There can only be one <ordering>
element in a web-fragment.xml 3. There can only be one <name> element
in a web-fragment.xml 6.
Update 8.2.2 to say � Artifacts
defined in WEB-INF/classes MUST be processed before processing the fragments
according to the rules specified below. 7.
Update section 8.2.3.5.d with the
following � Web fragments are merged into the main web.xml unless
metadata-complete is set to true. The merging takes place after annotation
processing on the corresponding fragment. 8.
Update section 8.2.3.5.g.i as follows
� �Elements that may be declared any number of times are additive across the
web-fragments in the resulting web.xml.� 9.
Add a
8.2.3.5.g.ii - Elements that may be declared any number of times, if specified
in the web.xml overrides the values specified in the web-fragments with the
same name.� 10. Updated
8.2.3.5.g.v to say <servlet-mapping> elements
are additive across web-fragments. <servlet-mapping>
declared in web.xml overrides the mapping for the servlet
specified in the web-fragment.xml 11. Updated
8.2.3.5.g.vi to say <filter-mapping> elements are additive across
web-fragments. < filter -mapping> declared in web.xml overrides the
mapping for the filter specified in the web-fragment.xml 12. Update
section 8.2.3.5.h.ii with the following -�
If a resource reference element is specified in two fragments, while
absent from the main web.xml, and all the attributes and child elements of the
resource reference element are identical, the resource reference will be
merged� into the main web.xml. It is
considered an error if a resource reference element has the same name specified
in two fragments, while absent from the main web.xml and the attributes and
child elements are not identical in the two fragments, an error must be
reported and the application MUST fail to deploy. For example, if two web
fragments declare a <resource-ref> with the same
<resource-ref-name> element but the type in one is specified as javax.sql.DataSource while the type in the other is that of
a JavaMail resource it is an error and the
application will fail to deploy. 13. Update
section 8.2.3.5.h.iii� Injection targets
from web fragments are additive for resource reference elements of the same
name in the web.xml. 14. Update
Section 8.2.3.5.j with the following - If a data-source element is specified in
two fragments, while absent from the main web.xml, and all the attributes and
child elements of the data-source element are identical, the data-source will
be merged into the main web.xml. It is considered an error if a
data-source element has the same name specified in two fragments, while absent
from the main web.xml and the attributes and child elements are not identical
in the two fragments. In such a case an error must be reported and the application
MUST fail to deploy. 15.
Update Section 8.2.4 with �The HandlesTypes annotation on the implementation of the ServletContainerInitializer is used to express interest in
classes that may have anotations (type, method or
field level annotations) specified in the value of the HandlesTypes
or if it extends / implements one those classes anywhere in the class� super
types. 16. �In 13.3
Programmatic Security, the spec� states" 17. �An
invalid tag name, i.e., "security-role-name" is used in section
13.4.1.2 - "Mapping @ServletSecurity to
security-constraint" and in section "13.4.1.3 Mapping @HttpConstraint and @HttpMethodConstraint
to XML." in the security chapter. The correct tag name should be
"role-name". 18.
On
page 130 : section 13.4.2 correct SecurityConstraintElement
to be ServletSecurityElement. 19.
The
following in the Servlet 3.0 spec page 137 : Should be replaced with <http-method-omission>GET</http-method-omission>
20.
Change
the following javadocs � ServletContext.getServletRegistrations: ServletSecurityElement.getHttpMethodConstraints If permitted,
any changes to the returned <code>Collection</code> must not affect this <code>ServletSecurityElement</code>. ServletSecurityElement.getMethodNames If
permitted, any changes to the returned <code>Collection</code> must
not affect this <code>ServletSecurityElement</code>. |
