ID |
Category |
Description |
C001 |
EE6 |
Rewrite section 2.3.2 Servlet as follows:
A JAX-RS application is packaged as a Web application in a .war
?le. The Application subclass (see section 2.1), resource classes, and providers are packaged in WEB-INF/classes, required libraries are packaged in WEB-INF/lib. Included libraries MAY also contain resource classes and providers as desired. See the Servlet speci?cation for full details on packaging of web applications.
When using a Servlet 3 container, the Application subclass is optional. By default, all root resource classes and providers packaged in the web
application willMUST be
included in the published JAX-RS application. An Application subclass MAY be included in a .war file to override the default behavior. If both getClasses and getSingletons return an empty list then the default willset of classes MUST be used. It is RECOMMENDED that implementations support the Servlet 3 framework pluggability mechanism to enable portability between containers and to avail themselves of container-supplied
class scanning facilities.
When using a non-JAX-RS aware servlet container, the servlet-class or filter-class element of the web.xml descriptor SHOULD name the JAX-RS implementation-supplied Servlet or
Filter class respectively. The application-supplied subclass of Application is identi?ed using an init-param with a param-name of javax.ws.rs.Application.
|
C002 |
EE6 |
Make section 6.2 Java EE Container normative and rewrite as follows:
This section describes the additional features available to an application hosted in a Java EE 6 container that supports JAX-RS.
An implementation MUST support applications packaged as described in section 2.3.2 Servlet. An implementation MUST support use of stateless session beans as root resource classes and providers in a Web application. JAX-RS annotations MAY be applied to a bean's local interface or directly to a no-interface bean.
Note: The new java:module JNDI context enables easy lookup of a stateless session bean instance given a bean local interface or class
name.
In a container that also includes support for JSR-299, an implementation MUST support use of JSR-299 beans as root resource classes, providers and as an Application subclass in a Web application. JAX-RS annotations MAY be directly applied to JSR-299 beans and the JAX-RS implementation MUST use JSR-299 APIs to obtain bean instances.
|
C003 |
Enhancement |
See Issue 55. Clarify handling of empty message bodies for standard message body readers. All bar JAXB will result in an empty (not null) object being passed to the resource method. Using the JAXB entity provider will result in a 400 client error. Add description of how to override default behavior using a custom provider. |
C004 |
Enhancement |
Add a secondary key to the sort order used when looking for compatible MessageBodyWriters such that writers whose declared generic type is closer in terms of inheritance are sorted earlier than those whose declared generic type is further. |
C005 |
Enhancement |
Specify that implementations should treat request messages without a specified Content-Type as application/octet-stream. The media type passed to a message body reader will never be null. |
C006 |
Enhancement |
Require support for static fromString method in addition to existing valueOf method for types used as parameters in resource methods. For backwards compatibility, where both methods exist, valueOf will take precedence except for Enums where the precedence is reversed since every enum defines an implicit valueOf method that cannot be overridden. |
C007 |
Enhancement |
See Issue 66. The current precondition-related methods of Request cannot
support "If-None-Match: *" which is typically used to prevent a request from being acted upon if a resource already exists at the request URI. Add a new method
to Request as follows:
/**
* Evaluate request preconditions for a resource that does not currently
* exist. The primary use of this method is to support the {@link <a
* href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.26">
* If-None-Match: *</a>} precondition.
*
* @return null if the preconditions are met or a ResponseBuilder set with
* the appropriate status if the preconditions are not met.
* @throws java.lang.IllegalStateException if called outside the scope of
* a request
*/
ResponseBuilder evaluatePreconditions();
|
C008 |
Enhancement |
See Issue 68. As suggested in the issue, add a new base interface to the Response.Status enum and switch methods of Response and ResponseBuilder that accept a Status to take an instance of the new interface instead. This will allow developers to create new status code enums that work with the API without having to resort to int values.
|
C009 |
Enhancement |
Add an @OPTIONS annotation to complete the set of pre-defined method designators. |
E001 |
Errata |
See Issue 51. Clarify that annotation inheritance applies to annotations on method parameters, not just annotations on methods. |
E002 |
Errata |
See Issue 52. Fix typo in Javadoc for Response.notAcceptable(): "vaue"->"value". |
E003 |
Errata |
See Issue 53. Fix Javadoc in MessageBodyReader and MessageBodyWriter to refer to Method.getGenericParameterTypes and Method.getParameterAnnotations, currently the documentation currently refers to those as being methods of Class. |
E004 |
Errata |
See Issue 56. Fix typo in Javadoc for Providers.getMessageBodyReader: "written"->"read". |
E005 |
Errata |
See Issue 57. Add example to Javadoc for MessageBodyReader.readFrom to illustrate difference between type and genericType. Be explicit about where null is allowed. |
E006 |
Errata |
See Issue 58. Re-order Javadoc for the parameters of Providers.getMessageBodyReader
and Providers.getMessageBodyWriter so that it matches parameter order. |
E007 |
Errata |
See Issue 59. Fix security context description in specification to refer to principal rather than principle. |
E008 |
Errata |
Fix type in CacheControl Javadoc: "empty list of cache extensions"->"empty map of cache extensions". |
E009 |
Errata |
Clarify that a valueOf method in type used as a resource method parameter must return the same type. |
E010 |
Errata |
Clarify that a 400 status code should be returned if an exception is raised during @FormParam-annotated parameter construction (appropriate status codes already specified for @PathParam, @QueryParam, @MatrixParam, @HeaderParam and @CookieParam). |
E011 |
Errata |
Servlet filters may trigger consumption of a request body by accessing request parameters. Clarify that in a servlet container the @FormParam annotation and the standard entity provider for application/x-www-form-urlencoded must obtain their values from the servlet request parameters if the request body has already been consumed. Include a note to the effect that because the servlet APIs do not differentiate between parameters in the URI and body of a request that URI-based query parameters may be included in the entity parameter. |
E012 |
Errata |
See Issue 64. Unify the javadoc for the value of @Consumes and @Produces as follows: /**
* A list of media types. Each entry may specify a single type or consist
* of a comma separated list of types. E.g. {"image/jpeg,image/gif",
* "image/png"}. Use of the comma-separated form allows definition of a
* common string constant for use on multiple targets.
*/
String[] value() default "*/*";
|
E013 |
Errata |
Fix typo in MessageBodyReader Javadoc: "Class.getParameterAnnotations"->"Method.getParameterAnnotations". |