Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSR 315 Maintenance Release

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 mergedinto 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.iiiInjection 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 specstates"
"The authenticate method allows an application to perform username and password collection (as an alternative to Form-Based Login). The login methods allow an application to instigate authentication of the request caller by the container from within an unconstrained request context." The descriptions have been inverted, it should say: "The login method allows an application to perform username and password collection (as an alternative to Form-Based Login). The authenticate method allows an application to instigate authentication of the request caller by the container from within an unconstrained request context."

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.
On page 133 : �The authenticate method of the HttpServletRequest interface provides an alternative means for an application to control the look and feel of its login screens.�
The above sentence will be replaced with �The login method of the HttpServletRequest interface provides an alternative means for an application to control the look and feel of its login screens."

19.      The following in the Servlet 3.0 spec page 137 :

<http-method-exception>GET</http-method-exception>
<http-method-exception>POST</http-method-exception>

Should be replaced with

<http-method-omission>GET</http-method-omission>
<http-method-omission>POST</http-method-omission>

 

20.      Change the following javadocs

ServletContext.getServletRegistrations:

  If permitted, any changes to the returned Map must not affect this  ServletContext.

- ServletRegistration.getMappings:

 If permitted, any changes to the returned <code>Collection</code> must not  affect this <code>ServletRegistration</code>.

FilterRegistration.getServletNameMappings:

 If permitted, any changes to the returned <code>Collection</code> must not  affect this <code>FilterRegistration</code>.

- FilterRegistration.getUrlPatternMappings:

 If permitted, any changes to the returned <code>Collection</code> must not  affect this <code>FilterRegistration</code>.

 

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