| ID | Chapter | Section | Description | Required | Dependency | Implementation Specific | Defined by | Status | Testable |
| Servlet:SPEC:1 | 1 | 2 | All servlet containers must support HTTP/1.0 and HTTP/1.1 protocols | true |
| false | technology | active | true |
| Servlet:SPEC:2 | 1 | 2 | Java SE 7 is the minimum version of the underlying Java platform with which containers must be built. | true |
| false | technology | active | false |
| Servlet:SPEC:269 | 1 | 6.1 | In Servlet 2.5, metadata-complete only affected the scanning of annotations at
deployment time. The notion of web-fragments did not exist in servlet 2.5. However
in servlet 3.0 and later, metadata-complete affects scanning of all annotations that
specify deployment information and web-fragments at deployment time. The
version of the descriptor MUST not affect which annotations you scan for in a web
application. An implementation of a particular version of the specification MUST
scan for all annotations supported in that configuration, unless metadata-complete
is specified.
| true |
| false | technology | active | true |
| Servlet:SPEC:3 | 2 | 2 | A servlet hosted in a non-distributed environment, the servlet container must use only one instance per servlet declaration. | true |
| false | technology | active | true |
| Servlet:SPEC:4 | 2 | 2 | A servlet deployed as part of an application marked in the deployment descriptor as distributable, a container may have only one instance per servlet declaration per virtual machine (VM). | true |
| false | technology | active | false |
| Servlet:SPEC:5 | 2 | 3 | The life cycle of a servlet is expressed in the API by the 'init', 'service', and 'destroy' methods of the jakarta.servlet.Servlet interface that all servlets must implement directly, or indirectly through the GenericServlet or HttpServlet abstract classes. | true |
| false | technology | active | true |
| Servlet:SPEC:6 | 2 | 3.1 | The servlet container is responsible for loading and instantiating servlets. | true |
| false | technology | active | true |
| Servlet:SPEC:6.1 | 2 | 3.1 | When the servlet engine is started, needed servlet classes must be located by the servlet container using normal Java class loading facilities. | true |
| false | technology | active | false |
| Servlet:SPEC:7 | 2 | 3.2 | After the servlet object is instantiated, the container must initialize the servlet before it can handle requests from clients by calling the init method of the Server interface with a unique (per servlet declaration) object implementing the ServerConfig interface. | true |
| false | technology | active | true |
| Servlet:SPEC:8 | 2 | 3.2.1 | The servlet container must not call the destroy method on a Servlet that threw an Exception during the initialization process. | true |
| false | technology | active | true |
| Servlet:SPEC:9 | 2 | 3.2.1 | A servlet throwing an UnavailableException that indicates a minimum time of unavailability, the container must wait for the period of time specified to pass before creating and initializing a new servlet instance. | true |
| false | technology | active | false |
| Servlet:SPEC:10 | 2 | 3.3.1 | For servlets where the service method (or methods such as doGet or doPost which are dispatched to the service method of the HttpServlet abstract class) has been defined with the synchronized keyword, the servlet container must serialize request through it. | true |
| false | technology | deprecated | true |
| Servlet:SPEC:11 | 2 | 3.3.2 | If a permanent unavailability is indicated by the UnavailableException, the servlet container must remove the servlet from service, call its destroy method, and release the servlet instance. | true |
| false | technology | active | true |
| Servlet:SPEC:11.1 | 2 | 3.3.2 | Any requests refused by the container by the cause, must be returned with a SC_NOT_FOUND(404) response. | true |
| false | technology | active | true |
| Servlet:SPEC:270 | 2 | 3.3.3 | public ServletRequest getRequest() - returns the request that was used to
initialize the AsyncContext by calling one of the startAsync methods. Calling
getRequest when complete or any of the dispatch methods has been
previously called in the asynchronous cycle will result in an IllegalStateException.
| true |
| false | technology | active | true |
| Servlet:SPEC:271 | 2 | 3.3.3 | public ServletResponse getResponse() - returns the response that was used
to initialize the AsyncContext by calling one of the startAsync methods.
Calling getResponse when complete or any of the dispatch methods has
been previously called in the asynchronous cycle will result in an
IllegalStateException.
| true |
| false | technology | active | true |
| Servlet:SPEC:272 | 2 | 3.3.5 | The servlet container provides an HTTP upgrade mechanism. However the servlet
container itself does not have knowledge about the upgraded protocol. The protocol
processing is encapsulated in the HttpUpgradeHandler.
Data reading or writing between the servlet container and the HttpUpgradeHandler is in byte streams..
| true |
| false | technology | active | true |
| Servlet:SPEC:273 | 2 | 3.3.5 | When an upgrade request is received, the servlet can invoke the
HttpServletRequest.upgrade method, which starts the upgrade process.
This method instantiates the given HttpUpgradeHandler class.
The returned HttpUpgradeHandler instance may be further customized. The application
prepares and sends an appropriate response to the client. After exiting the service
method of the servlet, the servlet container completes the processing of all filters and
marks the connection to be handled by the HttpUpgradeHandler. It then calls
the HttpUpgradeHandler's init method, passing a WebConnection to allow the protocol handler
access to the data streams.
| true |
| false | technology | active | true |
| Servlet:SPEC:274 | 2 | 3.3.5 | The servlet filters only process the initial HTTP request and response. They are not
involved in subsequent communications. In other words, they are not invoked once
the request has been upgraded.
| true |
| false | technology | active | true |
| Servlet:SPEC:275 | 2 | 3.3.5 | The HttpUpgradeHandler may use non blocking IO to consume and produce messages. | true |
| false | technology | active | true |
| Servlet:SPEC:299 | 2 | 3.3.5 | When the upgrade processing is done, HttpUpgradeHandler.destroy will be invoked. | true |
| false | technology | active | true |
| Servlet:SPEC:12 | 2 | 3.4 | When the servlet container determines that a Servlet should be removed from service, it must call the destroy method of the Servlet interface to allow the servlet to release any resources it is using and save any persistent state. | true |
| false | technology | active | false |
| Servlet:SPEC:12.1 | 2 | 3.4 | Before the container calls the destroy method, it must allow any threads that are currently running in the service method of the servlet to complete execution, or exceed a server defined time limit. | true |
| false | technology | active | false |
| Servlet:SPEC:12.2 | 2 | 3.4 | Once the destroy method is called on a servlet instance, the container must not route other requests to that instance of the Servlet. | true |
| false | technology | active | false |
| Servlet:SPEC:12.3 | 2 | 3.4 | After the destroy method completes, the servlet container must release the servlet instance so that it is eligible for garbage collection. | true |
| false | technology | active | false |
| Servlet:SPEC:20 | 3 | 1 | Data from the query string and the post body are aggregated into the request
parameter set. Query string data is presented before post body data.
| true |
| false | technology | active | true |
| Servlet:SPEC:21 | 3 | 1 | Path parameters that are a part of a GET request (as defined by HTTP 1.1) are not exposed by these APIs.
They must be parsed from the String values returned by the getRequestURI method or the getPathInfo method.
| true |
| false | technology | active | true |
| Servlet:SPEC:22 | 3 | 1.1 | The following conditions must be met before post form data will be populated to the parameter set: | true |
| false | technology | active | true |
| Servlet:SPEC:22.1 | 3 | 1.1 | The request is an HTTP or HTTPS request | true |
| false | technology | active | true |
| Servlet:SPEC:22.2 | 3 | 1.1 | The HTTP method is POST | true |
| false | technology | active | true |
| Servlet:SPEC:22.3 | 3 | 1.1 | The content type is application/x-www-form-urlencoded | true |
| false | technology | active | true |
| Servlet:SPEC:22.4 | 3 | 1.1 | The servlet has made an initial call to any of the getParameter family of methods on the request object. | true |
| false | technology | active | true |
| Servlet:SPEC:22.5 | 3 | 1.1 | If the conditions are not met, and the post form data is not included in the parameter
set, the post data must still be available to the servlet via the request object's input stream.
| true |
| false | technology | active | true |
| Servlet:SPEC:22.6 | 3 | 1.1 | If the conditions are met, post form data will no longer be available for
reading directly from the request object?s input stream.
| true |
| false | technology | active | true |
| Servlet:SPEC:276 | 3 | 2 | Servlet container allows files to be uploaded when data is sent as multipart/form-data. | true |
| false | technology | active | true |
| Servlet:SPEC:277 | 3 | 2 | The servlet container provides multipart/form-data processing if any one of the following conditions is met. | true |
| false | technology | active | true |
| Servlet:SPEC:277.1 | 3 | 2 | The servlet handling the request is annotated with the @MultipartConfig
as defined in Section 8.1.5, "@MultipartConfig" on page8-68.
| true |
| false | technology | active | true |
| Servlet:SPEC:277.2 | 3 | 2 | Deployment descriptors contain a multipart-config element for the servlet handling the request. | true |
| false | technology | active | true |
| Servlet:SPEC:278 | 3 | 2 | How data in a request of type multipart/form-data is made available depends on
whether the servlet container provides multipart/form-data processing:
| true |
| false | technology | active | true |
| Servlet:SPEC:278.1 | 3 | 2 | If the servlet container provides multipart/form-data processing,
the data is made available through the following methods in HttpServletRequest:
| true |
| false | technology | active | true |
| Servlet:SPEC:278.1.1 | 3 | 2 | public Collection <Part> getParts()
| true |
| false | technology | active | true |
| Servlet:SPEC:278.1.2 | 3 | 2 | public Part getPart(String name) | true |
| false | technology | active | true |
| Servlet:SPEC:278.1.3 | 3 | 2 | Each part provides access to the headers, content type related with it
and the content via the Part.getInputStream method.
| true |
| false | technology | active | true |
| Servlet:SPEC:278.1.4 | 3 | 2 | For parts with form-data as the Content-Disposition, but without a filename,
the string value of the part will also be available through the getParameter and
getParameterValues methods on HttpServletRequest, using the name of the part.
| true |
| false | technology | active | true |
| Servlet:SPEC:278.2 | 3 | 2 | If the servlet container does not provide the multi-part/form-data processing,
the data will be available through the HttpServletReuqest.getInputStream.
| true |
| false | technology | active | true |
| Servlet:SPEC:23 | 3 | 5 | (Servlet Path)This path starts with a '/' character except in the case
where the request is matched with the '/*' or "" pattern, in which case it is an
empty string.
| true |
| false | technology | active | true |
| Servlet:SPEC:24 | 3 | 5 | (Servlet Path)The path section that directly corresponds to the mapping which
activated this request. This path starts with a '/' character except...
| true |
| false | technology | active | true |
| Servlet:SPEC:25 | 3 | 5 | The part of the request path that is not part of the Context Path or the
Servlet Path. It is either null if there is no extra path, or is a string with a leading
'/'.
| true |
| false | technology | active | true |
| Servlet:SPEC:279 | 3 | 5 | It is important to note that, except for URL encoding differences between the request
URI and the path parts, the following equation is always true:
requestURI = contextPath + servletPath + pathInfo
| true |
| false | technology | active | true |
| Servlet:SPEC:280 | 3 | 6 | In situations where the servlet container cannot determine a valid file path for these
methods, such as when the Web application is executed from an archive, on a remote
file system not accessible locally, or in a database, these methods must return null.
| true |
| false | technology | active | true |
| Servlet:SPEC:281 | 3 | 6 | Resources inside the META-INF/resources directory of JAR file must be considered
only if the container has unpacked them from their containing JAR file when a call to
getRealPath() is made, and in this case MUST return the unpacked location.
| true |
| false | technology | active | true |
| Servlet:SPEC:282 | 3 | 7 | The ReadListener provides the following callback methods for non blocking IO -
| true |
| false | technology | active | true |
| Servlet:SPEC:282.1 | 3 | 7 | ReadListener.onDataAvailable(). The onDataAvailable method is invoked on the
ReadListener when data is available to read from the incoming request
stream. The container will invoke the method. This method will be invoked
once for every set of data available.
| true |
| false | technology | active | true |
| Servlet:SPEC:282.2 | 3 | 7 | ReadListener.onAllDataRead(). The onAllDataRead method is invoked when you have
finished reading all the data for the ServletRequest for which the listener was registered.
| true |
| false | technology | active | true |
| Servlet:SPEC:282.3 | 3 | 7 | ReadListener.onError(Throwable t). The onError method is invoked if there is any error or
exception that occurs while processing the request.
| true |
| false | technology | active | true |
| Servlet:SPEC:282.5 | 3 | 7 | boolean ServletInputStream.isFinished(). The isFinished method returns true when all the
data for the request associated with the ServletInputStream has been read.
Otherwise it returns false.
| true |
| false | technology | active | true |
| Servlet:SPEC:282.6 | 3 | 7 | boolean ServletInputStream.isReady(). The isReady method returns true if data can be read
without blocking. If no data can be read without blocking it returns false. If
isReady returns false it is illegal to call the read method and an
IllegalStateException MUST be thrown.
| true |
| false | technology | active | true |
| Servlet:SPEC:282.7 | 3 | 7 | void ServletInputStream.setReadListener(ReadListener listener). Sets the ReadListener
defined above to get invoked to read data in a non-blocking fashion. Once the
listener is associated for the given ServletInputStream, the container invokes
the methods on the ReadListener when data is available to read, all the data
has been read or if there was an error processing the request. Registering a
ReadListener will start non-blocking IO. It is illegal to switch to the traditional
blocking IO at that point and an IllegalStateException MUST be thrown.
A subsequent call to setReadListener in the scope of the current request is
illegal and an IllegalStateException MUST be thrown..
| true |
| false | technology | active | true |
| Servlet:SPEC:26 | 3 | 9 | If a request has been transmitted over a secure protocol, such as HTTPS, this
information must be exposed via the isSecure method of the ServletRequest
interface. The Web container must expose the following attributes to the servlet
programmer:
| true |
| false | platform | active | true |
| Servlet:SPEC:26.1 | 3 | 9 | attribute: cipher suite - attribute name: jakarta.servlet.request.cipher_suite - Java type: String | true |
| false | platform | active | true |
| Servlet:SPEC:26.2 | 3 | 9 | attribute: bit size of the algorithm - attribute name: jakarta.servlet.request.key_size - Java type: Integer | true |
| false | platform | active | true |
| Servlet:SPEC:26.4 | 3 | 9 | attribute: SSL session id - attribute name: jakarta.servlet.request.ssl_session_id - Java type: String | true |
| false | platform | active | true |
| Servlet:SPEC:26.3 | 3 | 9 | If there is an SSL certificate associated with the request, it must be exposed by the
servlet container to the servlet programmer as an array of objects of type
java.security.cert.X509Certificate and accessible via a ServletRequest
attribute of jakarta.servlet.request.X509Certificate.
| true |
| false | platform | active | true |
| Servlet:SPEC:26.3.1 | 3 | 9 | The order of this array (associated with the jakarta.servlet.request.X509Certificate request attribute)
is being defined as being in ascending order of trust.
The first certificate in the chain is the one set by the client,
the next is the one used to authenticate first, and so on.
| true |
| false | platform | active | true |
| Servlet:SPEC:27 | 3 | 11 | The default encoding of a request the container uses to create the request reader
and parse POST data must be "ISO-8859-1", if none has been specified by the client request.
| true |
| false | technology | active | true |
| Servlet:SPEC:28 | 3 | 11 | Calling the (setCharacterEncoding(String enc)) method after once data has been read will not affect the encoding. | true |
| false | technology | active | true |
| Servlet:SPEC:29 | 3 | 12 | Each request object is valid only within the scope of a servlet's service method, or
within the scope of a filter's doFilter method, unless the asynchronous processing
is enabled for the component and the startAsync method is invoked on the request object.
| true |
| false | technology | active | false |
| Servlet:SPEC:283 | 3 | 12 | In the case where asynchronous processing occurs, the request object remains
valid until complete is invoked on the AsyncContext.
| true |
| false | technology | active | true |
| Servlet:SPEC:305 | 3 | 12 | In case of upgrade, the above is still true.
| true |
| false | technology | active | true |
| Servlet:SPEC:13 | 4 | 2 | There is only one instance object of the ServletContext interface
associated with each web application deployed into a container.
| true |
| false | technology | active | true |
| Servlet:SPEC:14 | 4 | 2 | In cases where the container is distributed over many virtual machines,
a Web application will have an instance of the ServletContext for each JVM.
| true |
| false | technology | active | false |
| Servlet:SPEC:15 | 4 | 2 | A default ServletContext must be made available to servlets not deployed as a web application. | true |
| false | technology | active | false |
| Servlet:SPEC:15.1 | 4 | 2 | In a distributed container, the default ServletContext is non-distributable and must only exist in one VM. | true |
| false | technology | active | false |
| Servlet:SPEC:16 | 4 | 5 | Any attribute bound into a context is available to any other servlet
that is part of the same web application.
| true |
| false | technology | active | false |
| Servlet:SPEC:17 | 4 | 7 | Web servers may support multiple logical hosts sharing one IP address on a server.
This capability is sometimes referred to as "virtual hosting".
In this case, each logical host must have its own servlet context or set of servlet contexts.
Servlet contexts can not be shared across virtual hosts.
| true |
| false | technology | active | false |
| Servlet:SPEC:18 | 4 | 8 | Although a Container Provider implementation of a class reloading scheme
for ease of development is not required, any such implementation must ensure that all servlets,
and classes that they may use, are loaded in the scope of a single class loader.
| false |
| true | technology | active | false |
| Servlet:SPEC:18.1 | 4 | 8 | The full semantics of notification to session binding listeners
should be supported by containers for use in the monitoring of session termination
upon class reloading.
| false |
| true | technology | active | false |
| Servlet:SPEC:19 | 4 | 8.1 | Servlet containers must provide a private temporary directory for each servlet context. | true |
| false | technology | active | true |
| Servlet:SPEC:19.1 | 4 | 8.1 | (The container must) make it available via the jakarta.servlet.context.tempdir context attribute.
The objects associated with the attribute must be of type java.io.File.
| true |
| false | technology | active | true |
| Servlet:SPEC:19.2 | 4 | 8.1 | Servlet containers are required to ensure that the contents of the temporary directory
of one servlet context is not visible to the servlet contexts of other Web applications
running on the servlet container.
| true |
| false | technology | active | true |
| Servlet:SPEC:30 | 5 | 1 | A servlet container is allowed, but not required,
to buffer output going to the client for efficiency purposes.
| false |
| false | technology | active | false |
| Servlet:SPEC:31 | 5 | 1 | If a response has been committed and the reset or resetBuffer methods have been called,
an IllegalStateException must be thrown. The response and its associated buffer will be unchanged.
| true |
| false | technology | active | true |
| Servlet:SPEC:32 | 5 | 1 | When using a buffer, the container must immediately flush the contents of a filled buffer
to the client. If this is the first data sent to the client, the response is considered to be committed.
| true |
| false | technology | active | true |
| Servlet:SPEC:33 | 5 | 2 | To be successfully transmitted back to the client, headers must be set before the response is committed.
Headers set after the response is committed will be ignored by the servlet container.
| true |
| false | technology | active | true |
| Servlet:SPEC:34 | 5 | 2 | Servlet containers must not set a default content type when the servlet programmer does not set the type. | true |
| false | technology | active | true |
| Servlet:SPEC:183 | 5 | 2 | The setHeader method sets a header with a given name and value.
A previous header is replaced by the new header.
Where a set of header values exist for the name,
the values are cleared and replaced with the new value.
| true |
| false | technology | active | true |
| Servlet:SPEC:300 | 5 | 3 | Non-blocking IO only works with async request processing in Servlets and Filters
as defined in Section 2.3.3.3, "Asynchronous processing" on page 2-10,
and upgrade processing (as defined in Section 2.3.3.5, ?Upgrade Processing? on page 2-20).
| true |
| false | technology | active | true |
| Servlet:SPEC:306 | 5 | 3 | Otherwise, an IllegalStateException must be thrown when ServletInputStream.setReadListener
or ServletOutputStream.setWriteListener is invoked.
| true |
| false | technology | active | true |
| Servlet:SPEC:35 | 5 | 4 | If a partial URL is given and, for whatever reason, cannot be converted into a valid URL,
then this method(sendRedirect) must throw an IllegalArgumentException.
| true |
| false | technology | active | true |
| Servlet:SPEC:36 | 5 | 4 | These methods(sendError) will have the side effect of committing the response,
if it has not already been committed, and terminating it. No further output to the client should
be made by the servlet after these methods are called.
| true |
| false | technology | active | true |
| Servlet:SPEC:37 | 5 | 4 | These methods(sendRedirect) will have the side effect of commiting the response,
if it has not already been committed, and terminating it. No further output to the client should
be made by the servlet after these methods are called.
| true |
| false | technology | active | true |
| Servlet:SPEC:38 | 5 | 4 | If data has been written to the response buffer, but not returned to the client (i.e., the response is not committed), the data in the response buffer must be cleared and replaced with the data set by sendRedirect. | true |
| false | technology | active | true |
| Servlet:SPEC:39 | 5 | 4 | If data has been written to the response buffer,
but not returned to the client(i.e., the response is not committed),
the data in the response buffer must be cleared and replaced with the data set by sendError.
| true |
| false | technology | active | true |
| Servlet:SPEC:40 | 5 | 4 | If data is written to the response after sendRedirect has been called,
the data is ignored.
| true |
| false | technology | active | true |
| Servlet:SPEC:41 | 5 | 4 | If data is written to the response after sendError has been called,
the data is ignored.
| true |
| false | technology | active | true |
| Servlet:SPEC:284 | 5 | 6 | When a response is closed, the container must immediately flush all remaining
content in the response buffer to the client.
| true |
| false | technology | active | true |
| Servlet:SPEC:42 | 5 | 6 | The following events indicate that the servlet has satisfied the request
and that the response object is to be closed:
| true |
| false | technology | active | true |
| Servlet:SPEC:42.1 | 5 | 6 | The termination of the service method of the servlet. | true |
| false | technology | active | false |
| Servlet:SPEC:42.2 | 5 | 6 | The amount of content specified in the setContentLength
or setContentLengthLong method of the response
has been greater than zero and has been written to the response.
| true |
| false | technology | active | true |
| Servlet:SPEC:42.3 | 5 | 6 | The sendError method is called. | true |
| false | technology | active | true |
| Servlet:SPEC:42.4 | 5 | 6 | The sendRedirect method is called. | true |
| false | technology | active | true |
| Servlet:SPEC:42.5 | 5 | 6 | The complete method on AsyncContext is called. | true |
| false | technology | active | true |
| Servlet:SPEC:43 | 5 | 7 | Each response object is valid only within the scope of a servlet's service method,
or within the scope of a filter's doFilter method, unless the associated request object
has asynchronous processing enabled for the component.
| true |
| false | technology | active | false |
| Servlet:SPEC:285 | 5 | 7 | If asynchronous processing on the associated request is started,
then the request object remains valid until complete method on AsyncContext is called.
| true |
| false | technology | active | false |
| Servlet:SPEC:44 | 6 | 2.1 | After deployment of a web application,
and before a request causes the container to access a web resource,
The container must locate the list of filters that must be applied to the Web resource as described below.
| true |
| false | technology | active | false |
| Servlet:SPEC:45 | 6 | 2.1 | The container must ensure that it has instantiated a filter of the appropriate class
for each filter in the list, and called its init(FilterConfig config) method.
| true |
| false | technology | active | true |
| Servlet:SPEC:286 | 6 | 2.1 | The filter may throw an exception to indicate that it cannot function properly.
| true |
| false | technology | active | false |
| Servlet:SPEC:46 | 6 | 2.1 | If the exception thrown by a Filter is of type UnavailableException,
the container may examine the isPermanent attribute of the exception
and may choose to retry the filter at some later time.
| false |
| false | technology | active | false |
| Servlet:SPEC:47 | 6 | 2.1 | Only one instance per <filter> declaration in
the deployment descriptor is instantiated per JVM of the container.
The container provides the filter config as declared in the filter's deployment descriptor,
the reference to the ServletContext for the Web application, and the set of initialization parameters.
| true |
| false | technology | active | false |
| Servlet:SPEC:48 | 6 | 2.1 | When the container receives an incoming request it takes the first filter instance
in the list and calls its doFilter method, passing in the ServletRequest and ServletResponse,
and a reference to the FilterChain object it will use.
| true |
| false | technology | active | true |
| Servlet:SPEC:287 | 6 | 2.1 | The doFilter method of a filter will typically be implemented following this
or some subset of the following pattern:
| true |
| false | technology | active | false |
| Servlet:SPEC:287.1 | 6 | 2.1 | The method examines the request's headers. | true |
| false | technology | active | true |
| Servlet:SPEC:287.2 | 6 | 2.1 | The method may wrap the request object with a customized implementation of
ServletRequest or HttpServletRequest in order to modify request headers or data.
| true |
| false | technology | active | true |
| Servlet:SPEC:287.3 | 6 | 2.1 | The method may wrap the response object passed in to its doFilter method with a
customized implementation of ServletResponse or HttpServletResponse to
modify response headers or data.
| true |
| false | technology | active | true |
| Servlet:SPEC:287.4 | 6 | 2.1 | The filter may invoke the next entity in the filter chain. The next entity may be
another filter, or if the filter making the invocation is the last filter configured in the
deployment descriptor for this chain, the next entity is the target Web resource. The
invocation of the next entity is effected by calling the doFilter method on the
FilterChain object, and passing in the request and response with which it was
called or passing in wrapped versions it may have created.
| true |
| false | technology | active | true |
| Servlet:SPEC:50 | 6 | 2.1 | The filter chain's implementation of the doFilter method, provided by the
container, must locate the next entity in the filter chain and invoke its doFilter
method, passing in the appropriate request and response objects.
| true |
| false | technology | active | true |
| Servlet:SPEC:287.5 | 6 | 2.1 | Alternatively, the filter chain can block the request by not making the call
to invoke the next entity, leaving the filter responsible for filling out the response object.
| true |
| false | technology | active | true |
| Servlet:SPEC:287.6 | 6 | 2.1 | The service method is required to run in the same thread as all filters
that apply to the servlet.
| true |
| false | technology | active | true |
| Servlet:SPEC:287.7 | 6 | 2.1 | After invocation of the next filter in the chain, the filter may examine response
headers.
| true |
| false | technology | active | true |
| Servlet:SPEC:287.8 | 6 | 2.1 | Alternatively, the filter may have thrown an exception to indicate an error in
processing. If the filter throws an UnavailableException during its doFilter
processing, the container must not attempt continued processing down the filter
chain. It may choose to retry the whole chain at a later time if the exception is not
marked permanent.
| true |
| false | technology | active | true |
| Servlet:SPEC:287.9 | 6 | 2.1 | When the last filter in the chain has been invoked, the next entity accessed is the
target servlet or resource at the end of the chain.
| true |
| false | technology | active | true |
| Servlet:SPEC:49 | 6 | 2.1 | Before a filter instance can be removed from service by the container,
the container must first call the destroy method on the filter to enable the filter
to release any resources and perform other cleanup operations.
| true |
| false | technology | active | false |
| Servlet:SPEC:288 | 6 | 2.2 | When a filter invokes the doFilter method on the container's filter
chain implementation, the container must ensure that the request and response
object that it passes to the next entity in the filter chain, or to the target web resource
if the filter was the last in the chain, is the same object that was passed into the
doFilter method by the calling filter.
| true |
| false | technology | active | true |
| Servlet:SPEC:51 | 6 | 2.2 | The same requirement of wrapper object identity applies to the calls from a servlet
or a filter to RequestDispatcher.forward or RequestDispatcher.include, when
the caller wraps the request or response objects. In this case, the request and
response objects seen by the called servlet must be the same wrapper objects that
were passed in by the calling servlet or filter.
| true |
| false | technology | active | true |
| Servlet:SPEC:52 | 6 | 2.4 | The order the container uses in building the chain of filters to be applied for
a particular request URI is as follows:
| true |
| false | technology | active | true |
| Servlet:SPEC:52.1 | 6 | 2.4 | the <url-pattern> matching filter-mappings in the same order
that these elements appear in the deployment descriptor.
| true |
| false | technology | active | true |
| Servlet:SPEC:52.2 | 6 | 2.4 | The <servlet-name> matching filter-mappings in the same order
that these elements appear in the deployment descriptor.
| true |
| false | technology | active | true |
| Servlet:SPEC:53 | 6 | 2.4 | It is expected that high performance Web containers will cache filter chains
so that they do not need to compute them on a per-request basis.
| false |
| true | technology | active | false |
| Servlet:SPEC:302 | 6 | 2.5 | By using the new <dispatcher> element in the deployment descriptor,
the developer can indicate for a filter-mapping whether he would like the filter
to be applied to requests when:
| false |
| true | technology | active | true |
| Servlet:SPEC:54 | 6 | 2.5 | The request comes directly from the client.
This is indicated by a <dispatcher> element with value REQUEST,
| true |
| false | technology | active | true |
| Servlet:SPEC:58 | 6 | 2.5 | The request comes directly from the client.
This is indicated by the absence of any <dispatcher> elements.
| true |
| false | technology | active | true |
| Servlet:SPEC:55 | 6 | 2.5 | The request is being processed under a request dispatcher representing
the Web component matching the <url-pattern> or <servlet-name> using a forward() call.
This is indicated by a <distpatcher> element with value FORWARD.
| true |
| false | technology | active | true |
| Servlet:SPEC:56 | 6 | 2.5 | The request is being processed under a request dispatcher representing
the Web component matching the <url-pattern> or <servlet-name> using an include() call.
This is indicated by a <distpatcher> element with value INCLUDE.
| true |
| false | technology | active | true |
| Servlet:SPEC:57 | 6 | 2.5 | The request is being processed with the error page mechanism
specified in ?Error Handling? on page 106 to an error resource matching
the <url-pattern>. This is indicated by a <dispatcher> element
with the value ERROR.
| true |
| false | technology | active | true |
| Servlet:SPEC:301 | 6 | 2.5 | The request is being processed with the async context dispatch mechanism
specified in ?Asynchronous processing? on page 10 to a web component using a dispatch call.
This is indicated by a <dispatcher> element with the value ASYNC.
| true |
| false | technology | active | true |
| Servlet:SPEC:59 | 6 | 2.5 | (The container must be able to support) any combination of 1, 2, 3, 4 or 5 above. | true |
| false | technology | active | true |
| Servlet:SPEC:202 | 7 | 1.1 | Session tracking through HTTP cookies is the most used session tracking mechanism
and is required to be supported by all servlet containers.
| true |
| false | technology | active | true |
| Servlet:SPEC:303 | 7 | 1.1 | The container sends a cookie to the client.
The client will then return the cookie on each subsequent request to the server,
unambiguously associating the request with a session.
The name of the session tracking cookie must be JSESSIONID.
| true |
| false | technology | active | true |
| Servlet:SPEC:60 | 7 | 1.3 | When a client will not accept a cookie, URL rewriting may be used by the server
as the basis for session tracking. URL rewriting involves adding data, a session ID,
to the URL path that is interpreted by the container to associate the request with a session.
| true |
| false | technology | active | false |
| Servlet:SPEC:60.2 | 7 | 1.3 | The session ID must be encoded as a path parameter in the URL string. | true |
| false | technology | active | true |
| Servlet:SPEC:60.1 | 7 | 1.3 | The name of the parameter must be 'jsessionid'. | true |
| false | technology | active | true |
| Servlet:SPEC:61 | 7 | 1.4 | Web container must be able to support HTTP session tracking
while servicing HTTP request from clients that do no support the use of cookies.
| true |
| false | technology | active | false |
| Servlet:SPEC:62 | 7 | 2 | A session is considered 'new' if either of the following are true: | true |
| false | technology | active | true |
| Servlet:SPEC:62.1 | 7 | 2 | The client does not yet know about the session. | true |
| false | technology | active | true |
| Servlet:SPEC:62.2 | 7 | 2 | The client chooses not to join a session. | true |
| false | technology | active | true |
| Servlet:SPEC:63 | 7 | 3 | HttpSession objects must be scoped at the application (or servlet context) level. | true |
| false | technology | active | true |
| Servlet:SPEC:63.1 | 7 | 3 | The underlying mechanism, such as the cookies used to establish the session,
including the attributes in that object, must never be shared between context by the container.
| true |
| false | technology | active | true |
| Servlet:SPEC:63.2 | 7 | 3 | Additionally, sessions of a context must be resumable by requests into
that context regardless of whether their associated context was being accessed
directly or as the target of a request dispatch at the time the sessions were created.
| true |
| false | technology | active | true |
| Servlet:SPEC:64 | 7 | 4 | The valueBound method must be called before the object is made available vai the getAttribute method of the HttpSession interface. | true |
| false | technology | active | false |
| Servlet:SPEC:65 | 7 | 4 | The valueUnbound method must be called after the object is no longer available via the getAttribute method of the HttpSession interface. | true |
| false | technology | active | false |
| Servlet:SPEC:66 | 7 | 5 | The default timeout period for sessions is defined by the servlet container and can be obtained via the getMaxInactiveInterval method of the HttpSession interface. | true |
| false | technology | active | true |
| Servlet:SPEC:67 | 7 | 5 | Invalidation will not take effect until all servlets using that session have exited the service method. | true |
| false | technology | active | true |
| Servlet:SPEC:203 | 7 | 6 | The getLastAccessedTime method of the HttpSession interface allows a servlet to determine the last time the session was accessed before the current request. The session is considered to be accessed when a request that is part of the session is first handled by the servlet container. | true |
| false | technology | active | true |
| Servlet:SPEC:68 | 7 | 7.2 | Within an application marked as distributable, all request that are part of a session must be handled by one virtual machine at a time. | false |
| false | technology | active | false |
| Servlet:SPEC:69 | 7 | 7.2 | The container must be able to handle all objects placed into instances of the HttpSession class using the setAttribute or putValue methods appropriately, with the following restrictions: | true |
| false | technology | active | false |
| Servlet:SPEC:69.1 | 7 | 7.2 | The container must accept objects that implement the Serializable interface. | true |
| false | technology | active | false |
| Servlet:SPEC:69.2 | 7 | 7.2 | The container may choose to support storage of other designated objects in the HttpSession, such as references to Jakarta Enterprise Bean components and transactions. | false |
| false | technology | active | false |
| Servlet:SPEC:69.3 | 7 | 7.2 | Migration of sessions will be handled by container-specific facilities. | false |
| true | technology | active | false |
| Servlet:SPEC:70 | 7 | 7.2 | The distributed servlet container must throw an IllegalArgumentException for objects where the container cannot support the mechanism necessary for migration of the session storing them. | true |
| false | technology | active | false |
| Servlet:SPEC:71 | 7 | 7.2 | The distributed servlet container must support the mechanism necessary for migrating objects that implement Serializable. | true |
| false | technology | active | false |
| Servlet:SPEC:72 | 7 | 7.2 | Distributed servlet containers must support the mechanism necessary for migrating objects that implements Serializable. | true |
| false | platform | active | false |
| Servlet:SPEC:73 | 7 | 7.2 | If distributed contains persist or migrate sessions to provide quality of service features, they are not restricted to using the native JVM Serialization mechanism for serializing HttpSessions and their attributes. | false |
| true | technology | active | false |
| Servlet:SPEC:74 | 7 | 7.2 | Containers must notify any session attributes implementing the HttpSessionActivationListener during migration of a session. They must notify listeners of passivation prior to serialization of a session, and of activation after deserialization of a session | true |
| false | technology | active | false |
| Servlet:SPEC:307 | 8 | 1 | In a web application, classes using annotations will have their annotations processed
only if they are located in the WEB-INF/classes directory, or if they are packaged
in a jar file located in WEB-INF/lib within the application.
| true |
| false | technology | active | true |
| Servlet:SPEC:308 | 8 | 1 | The web application deployment descriptor contains a new ?metadata-complete?
attribute on the web-app element. The ?metadata-complete? attribute defines
whether the web descriptor is complete, or whether the class files of the jar file
should be examined for annotations and web fragments at deployment time. If
?metadata-complete? is set to "true", the deployment tool MUST ignore any
servlet annotations that specify deployment information present in the class files of
the application and web fragments. If the metadata-complete attribute is not
specified or is set to "false", the deployment tool must examine the class files of the
application for annotations, and scan for web fragments.
| true |
| false | technology | active | true |
| Servlet:SPEC:221 | 8 | 1.1 | This annotation(@WebServlet) is used to define a Servlet component in a web application. | true |
| false | technology | active | true |
| Servlet:SPEC:221.1 | 8 | 1.1 | This annotation is specified on a class and contains metadata about the Servlet being declared. | true |
| false | technology | active | true |
| Servlet:SPEC:221.2 | 8 | 1.1 | The urlPatterns or the value attribute on the annotation MUST be present. | true |
| false | technology | active | true |
| Servlet:SPEC:221.3 | 8 | 1.1 | All other attributes are optional with default settings (see javadocs for more details). | true |
| false | technology | active | true |
| Servlet:SPEC:221.4 | 8 | 1.1 | It is recommended to use value when the only attribute on the annotation is the url pattern and to use the urlPatterns attribute when the other attributes are also used. | false |
| false | technology | active | true |
| Servlet:SPEC:221.5 | 8 | 1.1 | It is illegal to have both value and urlPatterns attribute used together on the same annotation. | true |
| false | technology | active | false |
| Servlet:SPEC:221.6 | 8 | 1.1 | The default name of the Servlet if not specified is the fully qualified class name. | true |
| false | technology | active | true |
| Servlet:SPEC:221.7 | 8 | 1.1 | The annotated servlet MUST specify at least one url pattern to be deployed. | true |
| false | technology | active | true |
| Servlet:SPEC:221.8 | 8 | 1.1 | If the same servlet class is declared in the deployment descriptor under a different name,
a new instance of the servlet MUST be instantiated.
| true |
| false | technology | active | true |
| Servlet:SPEC:221.9 | 8 | 1.1 | If the same servlet class is added to the ServletContext via the programmatic API
defined in Section 4.4.1, "Programmatically adding and configuring Servlets" on page 4-35,
the attribute values declared via the @WebServlet annotation MUST be ignored and
a new instance of the servlet with the name specified MUST be created.
| true |
| false | technology | active | true |
| Servlet:SPEC:221.10 | 8 | 1.1 | Classes annotated with @WebServlet class MUST extend the jakarta.servlet.http.HttpServlet class. | true |
| false | technology | active | true |
| Servlet:SPEC:222 | 8 | 1.5 | This annotation(@MultipartConfig), when specified on a Servlet, indicates that the request it expects is of type mime/multipart. The HttpServletRequest object of the corresponding servlet MUST make available the mime attachments via the getParts and getPart methods to iterate over the various mime attachments. | true |
| false | technology | active | true |
| Servlet:SPEC:223 | 8 | 1.5 | The location attribute of the jakarta.servlet.annotation.MultipartConfig and the <location> element of the <multipart-config> is interpreted as an absolut path and defaults to the value of the jakarta.servlet.context.tempdir. | true |
| false | technology | active | true |
| Servlet:SPEC:224 | 8 | 1.5 | If a relative path is specified(in <location>), it will be relative to the tempdir location. | true |
| false | technology | active | true |
| Servlet:SPEC:225 | 8 | 1.5 | The test for absolute path vs relative path (in <location>) MUST be done via java.io.File.isAbsolute. | true |
| false | technology | active | true |
| Servlet:SPEC:226 | 8 | 2.1 | Using the annotations(@WebServlet, @WebFilter, @WebInitParam, @WebListener, @MultipartConfig)
defined above makes the use of web.xml optional.
| true |
| false | technology | active | true |
| Servlet:SPEC:227 | 8 | 2.1 | However for overriding either the default values or the values set via annotations,
the deployment descriptor is used.
| true |
| false | technology | active | true |
| Servlet:SPEC:228 | 8 | 2.1 | As before, if the metadata-complete element is set to true in the web.xml
descriptor, annotations that specify deployment information present
in the class files and web-fragments bundled in jars will not be processed.
It implies that all the metadata for the application is specified
via the web.xml descriptor.
| true |
| false | technology | active | true |
| Servlet:SPEC:229 | 8 | 2.1 | 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. The container will pick up and use the configuration as per the rules defined below. | true |
| false | technology | active | true |
| Servlet:SPEC:230 | 8 | 2.2 | A web-fragment.xml may have a top level <name> element of type javaee:java-identifierType.
There can only be one <name> element in a web-fragment.xml. If a <name> element is present,
it must be considered for the ordering of artifacts (unless the duplicate name exception applies, as described below).
| true |
| false | technology | active | true |
| Servlet:SPEC:231 | 8 | 2.2 | There can only be one <absolute-ordering> element in a web.xml. | true |
| false | technology | active | true |
| Servlet:SPEC:232 | 8 | 2.2 | The web.xml and WEB-INF/classes MUST be processed before any of the web-fragments
listed in the absolute-ordering element.
| true |
| false | technology | active | true |
| Servlet:SPEC:233 | 8 | 2.2 | Any <name> element direct children of the <absolute-ordering>
MUST be interpreted as indicating the absolute ordering in which those named web-fragments,
which may or may not be present, must be processed.
| true |
| false | technology | active | true |
| Servlet:SPEC:234 | 8 | 2.2 | The <absolute-ordering> element may contain zero or one <others /> element. | true |
| false | technology | active | true |
| Servlet:SPEC:235 | 8 | 2.2 | If the <absolute-ordering> element does not contain an <others/>
element, any web-fragment not specifically mentioned within <name /> elements
MUST be ignored.
| true |
| false | technology | active | true |
| Servlet:SPEC:236 | 8 | 2.2 | Excluded jars are not scanned for annotated servlets, filters or listeners. | true |
| false | technology | active | true |
| Servlet:SPEC:237 | 8 | 2.2 | However, if a servlet, filter or listener from an excluded jar is listed in web.xml
or a non-excluded web-fragment.xml, then it's annotations will apply unless otherwise
excluded by metadata-complete.
| true |
| false | technology | active | true |
| Servlet:SPEC:238 | 8 | 2.2 | ServletContextListeners discovered in TLD files of excluded jars are not
able to configure filters and servlets using the programmatic APIs.
Any attempt to do so will result in an IllegalStateException.
| true |
| false | platform | active | true |
| Servlet:SPEC:239 | 8 | 2.2 | If a discovered ServletContainerInitializer is loaded from an excluded jar,
it will be ignored. Irrespective of the setting of metadata-complete,
jars excluded by <absolute-ordering> elements are not scanned
for classes to be handled by any ServletContainerInitializer.
| true |
| false | technology | active | true |
| Servlet:SPEC:240 | 8 | 2.2 | Duplicate name exception: if, when traversing the children of <absolute-ordering>, multiple children with the same <name> element are encountered, only the first such occurrence must be considered. | true |
| false | technology | active | true |
| Servlet:SPEC:241 | 8 | 2.2 | There can only be one <ordering> element in a web-fragment.xml. | true |
| false | technology | active | true |
| Servlet:SPEC:242 | 8 | 2.2 | A web-fragment.xml may have an <ordering> element. If so, this element must contain zero or one <before> element and zero or one <after> element. | true |
| false | technology | active | true |
| Servlet:SPEC:243 | 8 | 2.2 | Duplicate name exception: if, when traversing the web-fragments, multiple members with the same <name> element are encountered, the application must log an informative error message including information to help fix the problem, and must fail to deploy. For example, one way to fix this problem is for the user to use absolute ordering, in which case relative ordering is ignored. | true |
| false | technology | active | true |
| Servlet:SPEC:244 | 8 | 2.2 | <before> means the document must be ordered before the document with the name matching what is specified within the nested <name> element. | true |
| false | technology | active | true |
| Servlet:SPEC:245 | 8 | 2.2 | <after> means the document must be ordered after the document with the name matching what is specified within the nested <name> element. | true |
| false | technology | active | true |
| Servlet:SPEC:246 | 8 | 2.2 | There is a special element <others/> which may be included zero or one time within the <before> or <after> element, or zero or one time directly within the <absolute-ordering> element. The
element must be handled as follows.
| true |
| false | technology | active | true |
| Servlet:SPEC:246.1 | 8 | 2.2 | If the <before> element contains a nested
, the document will be moved to the beginning of the list of sorted documents. If there are multiple documents stating <before>
, they will all be at the beginning of the list of sorted documents, but the ordering within the group of such documents is unspecified.
| true |
| false | technology | active | true |
| Servlet:SPEC:246.2 | 8 | 2.2 | If the <after> element contains a nested
, the document will be moved to the end of the list of sorted documents. If there are multiple documents requiring <after>
, they will all be at the end of the list of sorted documents, but the ordering within the group of such documents is unspecified.
| true |
| false | technology | active | true |
| Servlet:SPEC:246.3 | 8 | 2.2 | Within a <before> or <after> element, if an
element is present, but is not the only <name> element within its parent element, the other elements within that parent must be considered in the ordering process.
| true |
| false | technology | active | true |
| Servlet:SPEC:246.4 | 8 | 2.2 | If the
element appears directly within the <absolute-ordering> element, the runtime must ensure that any web-fragments not explicitly named in the <absolute-ordering> section are included at that point in the processing order. `
| true |
| false | technology | active | true |
| Servlet:SPEC:247 | 8 | 2.2 | If a web-fragment.xml file does not have an <ordering> or the web.xml does not have an <absolute-ordering> element the artifacts are assumed to not have any ordering dependency. | true |
| false | technology | active | true |
| Servlet:SPEC:248 | 8 | 2.2 | If the runtime discovers circular references, an informative message must be logged, and the application must fail to deploy. Again, one course of action the user may take is to use absolute ordering in the web.xml. | true |
| false | technology | active | false |
| Servlet:SPEC:249 | 8 | 2.3 | If the order in which the listeners, servlets, filters are invoked is important to an
application then a deployment descriptor must be used.
| true |
| false | technology | active | false |
| Servlet:SPEC:250 | 8 | 2.3 | when using annotations to define the listeners, servlets and filters, the order in which they are invoked is unspecified. | true |
| false | technology | active | true |
| Servlet:SPEC:251 | 8 | 2.3 | The order for listeners, servlets, filters if relevant must be specified in either the web-fragment.xml or the web.xml. | true |
| false | technology | active | true |
| Servlet:SPEC:252 | 8 | 2.3 | The ordering will be based on the order in which they are defined in the descriptor and on the absolute-ordering element in the web.xml or an ordering element in the web-fragment.xml, if present. | true |
| false | technology | active | true |
| Servlet:SPEC:253 | 8 | 2.3 | Filters that match a request are chained in the order in which they are declared in the web.xml. | true |
| false | technology | active | true |
| Servlet:SPEC:254 | 8 | 2.3 | Servlets are initialized either lazily at request processing time or eagerly during deployment. In the latter case, they are initialized in the order indicated by their load-on-startup elements. | true |
| false | technology | active | true |
| Servlet:SPEC:255 | 8 | 2.3 | The listeners are invoked in the order in which they are declared
in the web.xml as specified below:
| true |
| false | technology | active | true |
| Servlet:SPEC:255.1 | 8 | 2.3 | Implementations of jakarta.servlet.ServletContextListener are invoked at their contextInitialized method in the order in which they have been declared, and at their contextDestroyed method in reverse order. | true |
| false | technology | active | true |
| Servlet:SPEC:255.2 | 8 | 2.3 | Implementations of jakarta.servlet.ServletRequestListener are invoked at their requestInitialized method in the order in which they have been declared, and at their requestDestroyed method in reverse order. | true |
| false | technology | active | true |
| Servlet:SPEC:255.3 | 8 | 2.3 | Implementations of jakarta.servlet.http.HttpSessionListener are invoked at their sessionCreated method in the order in which they have been declared, and at their sessionDestroyed method in reverse order. | true |
| false | technology | active | true |
| Servlet:SPEC:255.4 | 8 | 2.3 | The methods of implementation of
jakarta.servlet.ServletContextAttributeListener,
jakarta.servlet.ServletRequestAttributeListener and
jakarta.servlet.HttpSessionAttributeListener are invoked in
the order in which they are declared when corresponding events are fired.
| true |
| false | technology | active | true |
| Servlet:SPEC:256 | 8 | 2.3 | If a servlet is disabled using the enabled element introduced in the web.xml then the servlet will not be available at the url-pattern specified for the servlet. | true |
| false | technology | active | true |
| Servlet:SPEC:257 | 8 | 2.3 | The web.xml of the web application has the highest precedence when resolving conflicts between the web.xml, web-fragment.xml and annotations. | true |
| false | technology | active | true |
| Servlet:SPEC:258 | 8 | 2.3 | If metadata-complete is not specified in the descriptors, or is set to false in the deployment descriptor, then the effective metadata for the application is derived by combining the metadata present in the annotations and the descriptors. The rules for merging are specified below - | true |
| false | technology | active | true |
| Servlet:SPEC:258.1 | 8 | 2.3 | Configuration settings in web fragments are used to augment those specified in the main web.xml in such a way as if they had been specified in the same web.xml. | true |
| false | technology | active | true |
| Servlet:SPEC:258.2 | 8 | 2.3 | The order in which configuration settings of web fragments are added to those in the main web.xml is as specified above in Section 8.2.2, Ordering of web.xml and web-fragment.xml on page 8-66 | true |
| false | technology | active | true |
| Servlet:SPEC:258.3 | 8 | 2.3 | The metadata-complete attribute when set to true in the main web.xml, is considered complete and scanning of annotations and fragments will not occur at deployment time. The absolute-ordering and ordering elements will be ignored if present. When set to true on a fragment, the metadata-complete attribute applies only to scanning of annotations in that particular jar. | true |
| false | technology | active | true |
| Servlet:SPEC:258.4 | 8 | 2.3 | Web fragments are merged into the main web.xml unless the metadata-complete is set to true. The merging takes place after annotation processing on the corresponding fragment. | true |
| false | technology | active | true |
| Servlet:SPEC:258.5 | 8 | 2.3 | The following are considered configuration conflicts when augmenting a web.xml with web fragments: | true |
| false | technology | active | true |
| Servlet:SPEC:258.5.1 | 8 | 2.3 | Multiple <init-param> elements with the same <param-name> but different <param-value> | true |
| false | technology | active | true |
| Servlet:SPEC:258.5.2 | 8 | 2.3 | Multiple <mime-mapping> elements with the same <extension> but different <mime-type> | true |
| false | technology | active | true |
| Servlet:SPEC:258.6 | 8 | 2.3 | The above configuration conflicts are resolved as follows | true |
| false | technology | active | true |
| Servlet:SPEC:258.6.1 | 8 | 2.3 | Configuration conflicts between the main web.xml and a web fragment are resolved such that the configuration in the web.xml takes precedence. | true |
| false | technology | active | true |
| Servlet:SPEC:258.6.2 | 8 | 2.3 | Configuration conflicts between two web fragments, where the element at the center of the conflict is not present in the main web.xml, will result in an error. An informative message must be logged, and the application must fail to deploy | true |
| false | technology | active | false |
| Servlet:SPEC:258.7 | 8 | 2.3 | After the above conflicts have been resolved, these additional rules are applied: | true |
| false | technology | active | true |
| Servlet:SPEC:258.7.1 | 8 | 2.3 | Elements that may be declared any number of times are additive across the web-fragments in the resulting web.xml. For example, <context-param> elements with different <param-name> are additive. | true |
| false | technology | active | true |
| Servlet:SPEC:258.7.2 | 8 | 2.3 | 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. | true |
| false | technology | active | true |
| Servlet:SPEC:258.7.3 | 8 | 2.3 | If an element with a minimum occurrence of zero, and a maximum occurrence of one, is present in a web fragment, and missing in the main web.xml, the main web.xml inherits the setting from the web fragment. If the element is present in both the main web.xml and the web fragment, the configuration setting in the main web.xml takes precedence. For example, if both the main web.xml and a web fragment declare the same servlet, and the servlet declaration in the web fragment specifies a <load-on-startup> element, whereas the one in the main web.xml does not, then the <load-on-startup> element from the web fragment will be used in the merged web.xml. | true |
| false | technology | active | true |
| Servlet:SPEC:258.7.4 | 8 | 2.3 | It is considered an error if an element with a minimum occurrence of zero, and a maximum occurrence of one, is specified differently in two web fragments, while absent from the main web.xml. For example, if two web fragments declare the same servlet, but with different <load-on-startup> elements, and the same servlet is also declared in the main web.xml, but without any <load-on-startup>, then an error must be reported. | true |
| false | technology | active | false |
| Servlet:SPEC:258.7.5 | 8 | 2.3 | <welcome-file> declarations are additive. | true |
| false | technology | active | true |
| Servlet:SPEC:258.7.6 | 8 | 2.3 | <servlet-mapping> elements with the same <servlet-name> are additive across web-fragments. <servlet-mapping> specified in the web.xml overrides values specified in the web-fragments with the same <servlet-name>. | true |
| false | technology | active | true |
| Servlet:SPEC:258.7.7 | 8 | 2.3 | <filter-mapping> elements with the same <filter-name> are add itive across web-fragments. <filter-mapping> specified in the web.xml overrides values specified in the web-fragments with the same <filter-name>. | true |
| false | technology | active | true |
| Servlet:SPEC:258.7.8 | 8 | 2.3 | Multiple <listener> elements with the same <listener-class> are treated as a single <listener> declaration | true |
| false | technology | active | true |
| Servlet:SPEC:258.7.9 | 8 | 2.3 | The web.xml resulting from the merge is considered <distributable> only if all its web fragments are marked as <distributable> as well. | true |
| false | technology | active | true |
| Servlet:SPEC:258.7.10 | 8 | 2.3 | The top-level <icon> and it's children elements, <display-name>>, and <description> elements of a web fragment are ignored. | true |
| false | technology | active | true |
| Servlet:SPEC:258.7.11 | 8 | 2.3 | jsp-property-group is additive. It is recommended that jsp-config element use the url-pattern as opposed to extension mappings when bundling static resources in the META-INF/resources directory of a jar file. Further more JSP resources for a fragment should be in a sub-directory same as the fragment name, if there exists one. This helps prevent a web-fragment's jsp-property-group from affecting the JSPs in the main docroot of the application and the jsp-property-group from affecting the JSPs in a fragment's META-INF/resources directory. | true |
| false | platform | active | true |
| Servlet:SPEC:258.8 | 8 | 2.3 | For all the resource reference elements (env-entry, ejb-ref, ejb-local-ref, service-ref, resource-ref, resource-env-ref, message-destination-ref, persistence-context-ref and persistence-unit-ref) the following rules apply: | true |
| false | platform | active | true |
| Servlet:SPEC:258.8.1 | 8 | 2.3 | If any resource reference element is present in a web fragment, and is missing in the main web.xml, the main web.xml inherits the value from the web fragment. If the element is present in both the main web.xml and the web fragment, with the same name, the web.xml takes precedence. None of the child elements from the fragment are merged into the main web.xml except for the injection-target as specified below. For example, if both the main web.xml and a web fragment declare a <resource-ref> with the same <resource-ref-name>, the <resource-ref> from the web.xml will be used without any child elements being merged from the fragment except <injection-target> as described below. | true |
| false | platform | active | true |
| Servlet:SPEC:258.8.2 | 8 | 2.3 | 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 | true |
| false | platform | active | true |
| Servlet:SPEC:258.8.3 | 8 | 2.3 | For resource reference element with the same name <injection-target> elements from the fragments will be merged into the main web.xml. | true |
| false | platform | active | true |
| Servlet:SPEC:258.9 | 8 | 2.3 | In addition to the merging rules for web-fragment.xml defined above, the following rules apply when using the resource reference annotations (@Resource, @Resources, @EJB, @EJBs, @WebServiceRef, @WebServiceRefs, @PersistenceContext, @PersistenceContexts,@PersistenceUnit, and @PersistenceUnits) | true |
| false | platform | active | true |
| Servlet:SPEC:258.9.1 | 8 | 2.3 | If a resource reference annotation is applied on a class, it is equivalent to defining a resource, however it is not equivalent to defining an injection-target. The rules above apply for injection-target element in this case. | true |
| false | platform | active | true |
| Servlet:SPEC:258.9.2 | 8 | 2.3 | If a resource reference annotation is used on a field it is equivalent to defining the injection-target element in the web.xml. However if there is no injection-target element in the descriptor then the injection-target from the fragments will still be merged into the web.xml as defined above. | true |
| false | platform | active | true |
| Servlet:SPEC:258.9.3 | 8 | 2.3 | If on the other hand there is an injection-target in the main web.xml and there is a resource reference annotation with the same resource name, then it is considered an override for the resource reference annotation. In this case since there is an injection-target specified in the descriptor, the rules defined above would apply in addition to overriding the value for the resource reference annotation. | true |
| false | platform | active | true |
| Servlet:SPEC:258.10 | 8 | 2.3 | 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. | true |
| false | platform | active | true |
| Servlet:SPEC:258.11 | 8 | 2.3 | If the main web.xml does not have any <post-construct> element specified and web-fragments have specified <post-construct> then the <post-construct> elements from the fragments will be merged into the main web.xml. However if in the main web.xml at least one <post-construct> element is specified then the <post-construct> elements from the fragment will not be merged. It is the responsibility of the author of the web.xml to make sure that the <post-construct> list is complete. | true |
| false | technology | active | true |
| Servlet:SPEC:258.12 | 8 | 2.3 | If the main web.xml does not have any <pre-destroy> element specified and web-fragments have specified <pre-destroy> then the <pre-destroy> elements from the fragments will be merged into the main web.xml. However if in the main web.xml at least one <pre-destroy> element is specified then the <pre-destroy> elements from the fragment will not be merged. It is the responsibility of the author of the web.xml to make sure that the <pre-destroy> list is complete. | true |
| false | technology | active | true |
| Servlet:SPEC:258.13 | 8 | 2.3 | After processing the web-fragment.xml, annotations from the corresponding fragment are processed to complete the effective metadata for the fragment before processing the next fragment. The following rules are used for processing annotations: | true |
| false | technology | active | true |
| Servlet:SPEC:258.14 | 8 | 2.3 | Any metadata specified via an annotation that isn't already present in the descriptor will be used to augment the effective descriptor. | true |
| false | technology | active | true |
| Servlet:SPEC:258.14.1 | 8 | 2.3 | Configuration specified in the main web.xml or a web fragment takes precedence over the configuration specified via annotations. | true |
| false | technology | active | true |
| Servlet:SPEC:258.14.2 | 8 | 2.3 | For a servlet defined via the @WebServlet annotation, to override values via the descriptor, the name of the servlet in the descriptor MUST match the name of the servlet specified via the annotation (explicitly specified or the default name, if one is not specified via the annotation). | true |
| false | technology | active | true |
| Servlet:SPEC:258.14.3 | 8 | 2.3 | Init params for servlets and filters defined via annotations, will be overridden in the descriptor if the name of the init param exactly matches the name specified via the annotation. Init params are additive between the annotations and descriptors. | true |
| false | technology | active | true |
| Servlet:SPEC:258.14.4 | 8 | 2.3 | url-patterns, when specified in a descriptor for a given servlet name overrides the url patterns specified via the annotation. | true |
| false | technology | active | true |
| Servlet:SPEC:258.14.5 | 8 | 2.3 | For a filter defined via the @WebFilter annotation, to override values via the descriptor, the name of the filter in the descriptor MUST match the name of the filter specified via the annotation (explicitly specified or the default name, if one is not specified via the annotation). | true |
| false | technology | active | true |
| Servlet:SPEC:258.14.6 | 8 | 2.3 | url-patterns to which a filter is applied, when specified in a descriptor for a given filter name overrides the url patterns specified via the annotation. | true |
| false | technology | active | true |
| Servlet:SPEC:258.14.7 | 8 | 2.3 | DispatcherTypes to which a filter applies, when specified in a descriptor for a given filter name overrides the DispatcherTypes specified via the annotation. | true |
| false | technology | active | true |
| Servlet:SPEC:259 | 8 | 2.4 | In addition to supporting fragments and use of annotations one of the requirements is
that not only we be able to plug-in things that are bundled in the WEB-INF/lib
but also plugin shared copies of frameworks - including being able to plug-in
to the web container things like JAX-WS, JAX-RS and JSF that build on top of the web container.
The ServletContainerInitializer allows handling such a use case as described below.
| true |
| false | platform | active | true |
| Servlet:SPEC:259.1 | 8 | 2.4 | The ServletContainerInitializer class is looked up via the jar services API.
For each application, an instance of the ServletContainerInitializer is created
by the container at application startup time.
The framework providing an implementation of the ServletContainerInitializer MUST bundle
in the META-INF/services directory of the jar file a file called
jakarta.servlet.ServletContainerInitializer, as per the jar services API,
that points to the implementation class of the ServletContainerInitializer.
| true |
| false | platform | active | true |
| Servlet:SPEC:259.2 | 8 | 2.4 | In addition to the ServletContainerInitializer we also have an annotation - HandlesTypes.
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.
The HandlesTypes annotation is applied irrespective of the setting of metadata-complete.
The container uses the HandlesTypes annotation to determine when to invoke the initializer's
onStartup method.
When examining the classes of an application to see if they match any of the criteria
specified by the HandlesTypes annotation of a ServletContainerInitializer,
the container may run into class loading problems if one or more of the application's
optional JAR files are missing.
Since the container is not in a position to decide whether these types of class
loading failures will prevent the application from working correctly,
it must ignore them, while at the same time providing a configuration option that would log them.
| true |
| false | platform | active | true |
| Servlet:SPEC:259.3 | 8 | 2.4 | If an implementation of ServletContainerInitializer does not have the @HandlesTypes annotation,
or if there are no matches to any of the HandlesType specified,
then it will get invoked once for every application with null as the value of the Set.
This will allow for the initializer to determine based on the resources available
in the application whether it needs to initialize a servet / filter or not.
| true |
| false | platform | active | true |
| Servlet:SPEC:259.4 | 8 | 2.4 | The onStartup method of the ServletContainerInitializer will be invoked when the application is coming up before any of the listener's events are fired. | true |
| false | platform | active | true |
| Servlet:SPEC:259.5 | 8 | 2.4 | The ServletContainerInitializer's onStartup method get's a Set of Classes that either extend / implement the classes that the initializer expressed interest in or if it is annotated with any of the classes specified via the @HandlesTypes annotation. | true |
| false | platform | active | true |
| Servlet:SPEC:259.6 | 8 | 2.4 | The framework jar file can also be bundled in WEB-INF/lib directory of the war file.
If the ServletContainerInitializer is bundled in a JAR file inside the WEB-INF/lib
directory of an application, it's onStartup method will be invoked only once
during the startup of the bundling application. If, on the other hand, the ServletContainerInitialzer is bundled
in a JAR file outside of the WEB-INF/lib directory, but still discoverable
by the runtime's service provider lookup mechanism,
it's onStartup method will be invoked every time an application is started.
| true |
| false | platform | active | true |
| Servlet:SPEC:259.7 | 8 | 2.4 | Implementations of the ServletContainerInitializer interface will be discovered by the runtime's service lookup mechanism or a container specific mechanism that is semantically equivalent to it. In either case, ServletContainerInitializer services from web fragment JAR files that are excluded from an absolute ordering MUST be ignored, and the order in which these services are discovered MUST follow the application's class loading delegation model. | true |
| false | platform | active | true |
| Servlet:SPEC:260 | 8 | 3 | The ServletContainerInitializer and programmatic registration features make it possible to provide a clear separation of responsibilities between the Servlet and JSP containers, by making the Servlet container responsible for parsing only web.xml and web-fragment.xml resources, and delegating the parsing of Tag Library Descriptor (TLD) resources to the JSP container. ` | true |
| false | platform | active | true |
| Servlet:SPEC:261 | 8 | 3 | Previously, a web container had to scan TLD resources for any listener declarations. With Servlet 3.0, this responsibility may be delegated to the JSP container. A JSP container that is embedded in a Servlet 3.0 compliant Servlet container may provide its own ServletContainerInitializer implementation, search the ServletContext passed to its onStartup method for any TLD resources, scan those resources for listener declarations, and register the corresponding listeners with the ServletContext. | true |
| false | platform | active | true |
| Servlet:SPEC:262 | 8 | 3 | In addition, prior to Servlet 3.0, a JSP container used to have to scan an application's deployment descriptor for any jsp-config related configuration. With Servlet 3.0, the Servlet container must make available, via the ServletContext.getJspConfigDescriptor method, any jsp-config related configuration from the application's web.xml and web-fragment.xml deployment descriptors. | true |
| false | platform | active | true |
| Servlet:SPEC:263 | 8 | 3 | Any ServletContextListeners that were discovered in a TLD and registered programmatically are limited in the functionality they provide. Any attempt to call a ServletContext API method on them that was added in Servlet 3.0 will result in an UnsupportedOperationException. | true |
| false | platform | active | true |
| Servlet:SPEC:264 | 8 | 3 | In addition, a Servlet 3.0 compliant Servlet container must provide a ServletContext attribute with name jakarta.servlet.context.orderedLibs, whose value (of type java.util.List<java.lang.String>) contains the list of names of JAR files in the WEB-INF/lib directory of the application represented by the ServletContext, ordered by their web fragment names (with possible exclusions if fragment JAR files have been excluded from absolute-ordering), or null if the application does not specify any absolute or relative ordering. | true |
| false | platform | active | true |
| Servlet:SPEC:265 | 8 | 4 | Web applications can include both annotations and the web.xml / web-fragment.xml deployment descriptors. | true |
| false | technology | active | true |
| Servlet:SPEC:266 | 8 | 4 | . If there is no deployment descriptor, or there is one but does not have the metadata-complete set to true, web.xml, web-fragment.xml and annotations if used in the application must be processed. | true |
| false | technology | active | true |
| Servlet:SPEC:267 | 8 | 4 | The following table (Table 8-1) describes whether or not to process annotations and web.xml fragments. | true |
| false | technology | active | true |
| Servlet:SPEC:75 | 9 | 2 | The Container provider must ensure that the dispatch of the request to a target servlet
occurs in the same thread of the same VM as the original request.
| true |
| false | technology | active | false |
| Servlet:SPEC:192 | 9 | 3 | The include method of the RequestDispatcher interface may be called at any time. The target servlet of the include method has access to all aspects of the request object, but its use of the response object is more limited. | true |
| false | technology | active | true |
| Servlet:SPEC:192.1 | 9 | 3 | It can only write information to the ServletOutputStream or Writer of the response object | true |
| false | technology | active | true |
| Servlet:SPEC:192.2 | 9 | 3 | commit a response by writing content past the end of the response buffer | true |
| false | technology | active | true |
| Servlet:SPEC:192.3 | 9 | 3 | commit a response by explicitly calling the flushBuffer method of the ServletResponse interface. | true |
| false | technology | active | true |
| Servlet:SPEC:192.4 | 9 | 3 | It cannot set headers or call any method that affects the headers of the response, with the exception of the HttpServletRequest. getSession() and HttpServletRequest.getSession(boolean) methods. Any attempt to set the headers must be ignored, and any call to HttpServletRequest. getSession() or HttpServletRequest.getSession( boolean) that would require adding a Cookie response header must throw an IllegalStateException if the response has been committed. | true |
| false | technology | active | true |
| Servlet:SPEC:76 | 9 | 3.1 | Except for servlets obtained by using the getNamedDispatcher method, a servlet being used from within an include has access to the path by which it was invoked. The following request attributes are set: | true |
| false | technology | active | true |
| Servlet:SPEC:76.1 | 9 | 3.1 | 'jakarta.servlet.include.request_uri' which is the URI by which it was invoked. | true |
| false | technology | active | true |
| Servlet:SPEC:76.2 | 9 | 3.1 | 'jakarta.servlet.include.context_path' which is the context path portion of the request URI by which it was invoked. | true |
| false | technology | active | true |
| Servlet:SPEC:76.3 | 9 | 3.1 | 'jakarta.servlet.include.servlet_path' the servlet-path portion of the request URI by which it was invoked. | true |
| false | technology | active | true |
| Servlet:SPEC:76.4 | 9 | 3.1 | 'jakarta.servlet.include.path_info' the path-info portion of the request URI by which it was invoked. | true |
| false | technology | active | true |
| Servlet:SPEC:76.5 | 9 | 3.1 | 'jakarta.servlet.include.query_string' the query string portion of the request URI by which it was invoked. | true |
| false | technology | active | true |
| Servlet:SPEC:77 | 9 | 4 | If output data exists in the response buffer that has not been committed, the content must be cleared before the target's service method is called. | true |
| false | technology | active | true |
| Servlet:SPEC:78 | 9 | 4 | The path elements of the request object exposed to the target servlet must reflect the path used to obtain the RequestDispatcher. | true |
| false | technology | active | true |
| Servlet:SPEC:79 | 9 | 4 | If the RequestDispatcher was obtained through getNamedDispatcher the path elements of the request object must reflect those of the original request. | true |
| false | technology | active | false |
| Servlet:SPEC:80 | 9 | 4 | Before the forward method of the RequestDispatcher interface returns without exception,
the response content must be sent and committed, and closed by the servlet container,
unless the request was put into the asynchronous mode
| true |
| false | technology | active | true |
| Servlet:SPEC:81 | 9 | 4.1 | The request dispatching mechanism is responsible for aggregating query string parameters when forwarding or including requests. | true |
| false | technology | deprecated | true |
| Servlet:SPEC:180 | 9 | 4.2 | Except for servlets obtained by using the getNamedDispatcher method, a servlet that has been invoked by another servlet using the forward method of RequestDispatcher has access to the path of the original request. The values of these attributes must be equal to the return values of the HttpServletRequest methods getRequestURI, getContextPath, getServletPath, getPathInfo, getQueryString respectively, invoked on the request object passed to the first servlet object in the call chain that received the request from the client. These attributes are accessible from the forwarded servlet via the getAttribute method on the request object. Note that these attributes must always reflect the information in the original request even under the situation that multiple forwards and subsequent includes are called. If the forwarded servlet was obtained by using the getNamedDispatcher method, these attributes must not be set. | true |
| false | technology | active | true |
| Servlet:SPEC:180.1 | 9 | 4.2 | jakarta.servlet.forward.request_uri | true |
| false | technology | active | true |
| Servlet:SPEC:180.2 | 9 | 4.2 | jakarta.servlet.forward.context_path | true |
| false | technology | active | true |
| Servlet:SPEC:180.3 | 9 | 4.2 | jakarta.servlet.forward.servlet_path | true |
| false | technology | active | true |
| Servlet:SPEC:180.4 | 9 | 4.2 | jakarta.servlet.forward.path_info | true |
| false | technology | active | true |
| Servlet:SPEC:180.5 | 9 | 4.2 | jakarta.servlet.forward.query_string | true |
| false | technology | active | true |
| Servlet:SPEC:181 | 9 | 4.2 | If the forwarded servlet was obtained by using the getNamedDispatcher method, these attributes must not be set. | true |
| false | technology | active | true |
| Servlet:SPEC:181.1 | 9 | 4.2 | jakarta.servlet.forward.request_uri | true |
| false | technology | active | true |
| Servlet:SPEC:181.2 | 9 | 4.2 | jakarta.servlet.forward.context_path | true |
| false | technology | active | true |
| Servlet:SPEC:181.3 | 9 | 4.2 | jakarta.servlet.forward.servlet_path | true |
| false | technology | active | true |
| Servlet:SPEC:181.4 | 9 | 4.2 | jakarta.servlet.forward.path_info | true |
| false | technology | active | true |
| Servlet:SPEC:181.5 | 9 | 4.2 | jakarta.servlet.forward.query_string | true |
| false | technology | active | true |
| Servlet:SPEC:82 | 9 | 5 | If the servlet that is the target of a request dispatcher throws a runtime exception or a checked exception of type ServletException or IOException, it may be propagated to the calling servlet. | true |
| false | technology | active | false |
| Servlet:SPEC:83 | 9 | 5 | All other exceptions (not a runtime, ServletException, or IOException) should be wrapped as ServletExceptions with the root cause the original exception before propagation. | true |
| false | technology | active | true |
| Servlet:SPEC:84 | 10 | 1 | An instance of a web application, by default, must run on one VM at any one time. | true |
| false | technology | active | false |
| Servlet:SPEC:85 | 10 | 1 | An application marked as distributable must obey a more restrictive set of rules than is required of a normal web application (the rules are set through out this list.) | true |
| false | technology | active | false |
| Servlet:SPEC:86 | 10 | 2 | The servlet container must enforce a one to one correspondence between a web application and a ServletContext. A ServletContext object provides a servlet with its view of the application. | true |
| false | technology | active | false |
| Servlet:SPEC:87 | 10 | 5 | Since the context path of an application determines the URL namespace of the context of the web application, web containers must reject web application defining a context path could cause potential conflicts in this URL namespace. | true |
| false | technology | active | false |
| Servlet:SPEC:88 | 10 | 5 | Since request are matched to resources case sensitively, this determination of potential context path namespace conflicts must be performed case sensitively as well. | true |
| false | technology | active | false |
| Servlet:SPEC:89 | 10 | 5 | The WEB-INF node (or directory) of a web application is not part of the public document tree of the application. Any requests to access the resources in /WEB-INF directory must be returned with a SC_NOT_FOUND(404) response. | true |
| false | technology | active | true |
| Servlet:SPEC:90 | 10 | 5 | The contents of /WEB-INF are visible to Servlets through the use of ServletContext.getResource or ServletContext.getSourceAsStream. | true |
| false | technology | active | true |
| Servlet:SPEC:91 | 10 | 5 | The web applcation classloader must load classes from the WEB-INF/ classes directory first, and then from the library JARs in the WEB-INF directory. | true |
| false | technology | active | true |
| Servlet:SPEC:92 | 10 | 6 | When web applications are packaged in a WAR file (Web ARchive file), a META-INF directory will be present which contains information useful to Java Archive tools. | true |
| false | technology | active | true |
| Servlet:SPEC:92.1 | 10 | 6 | Any requests to the META-INF directory of a packaged web application will be returned with a SC_NOT_FOUND(404) response. | true |
| false | technology | active | true |
| Servlet:SPEC:92.2 | 10 | 6 | The content of the META-INF directory of a packaged web application is accessible to servlets using the getResource and getResourceAsStream methods of the ServletContext. | true |
| false | technology | active | true |
| Servlet:SPEC:93 | 10 | 7.1 | Jakarta EE technology-compliant containers are required to provide a mechanism by which a deployer can learn what JAR files containing resources and code are available for the Web application. | true |
| true | technology | active | false |
| Servlet:SPEC:97 | 10 | 7.1 | Containers should provide a convenient procedure for editing and configuring library files or extensions. | false |
| true | technology | active | false |
| Servlet:SPEC:94 | 10 | 7.1 | During deployment of the Web application, the Web container must make the correct versions of the extensions available to the application following the rules defined by the Optional Package Versioning mechanism (https://docs.oracle.com/javase/8/docs/technotes/guides/extensions/extensions.html). | true |
| false | technology | active | false |
| Servlet:SPEC:95 | 10 | 7.1 | Web containers must also be able to recognize declared dependencies expressed in the manifest entry of any of the library JARs under the WEB-INF/lib entry in a WAR. | true |
| false | technology | active | false |
| Servlet:SPEC:96 | 10 | 7.1 | If a web container is not able to satisfy the dependencies declared via manifest files, it should reject the application with an informative error message. | false |
| false | technology | active | false |
| Servlet:SPEC:98 | 10 | 7.2 | The classloader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal Java SE semantics using getResource. | true |
| false | technology | active | true |
| Servlet:SPEC:99 | 10 | 7.2 | As described in the Jakarta EE license agreement, servlet containers that are not part of a Jakarta EE product should not allow the application to override Java SE platform classes, such as those in the java.* and javax.* namespaces, that Java SE does not allow to be modified. | true |
| false | technology | active | true |
| Servlet:SPEC:99.1 | 10 | 7.2 | Also, servlet containers that are part of a Jakarta EE product should not allow the application to override Java SE or Jakarta EE platform classes, such as those in the java.* and javax.* namespaces, that either Java SE or Jakarta EE do not allow to be modified. | true |
| false | technology | active | true |
| Servlet:SPEC:99.2 | 10 | 7.2 | The class loader that a container uses to load a servlet in a WAR must allow the developer to load any resources contained in library JARs within the WAR following normal Java SE semantics using getResource. | true |
| false | technology | active | true |
| Servlet:SPEC:99.3 | 10 | 7.2 | It is recommended also that the application class loader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs. | true |
| false | technology | active | true |
| Servlet:SPEC:100 | 10 | 7.2 | It is recommended that the loader not allow servlets in the WAR access to the web container's implementation classes. | false |
| false | technology | active | false |
| Servlet:SPEC:101 | 10 | 7.2 | It is recommended also that the application classloader be implemented so that classes and resources packaged within the WAR are loaded in preference to classes and resources residing in container-wide library JARs. | false |
| false | technology | active | false |
| Servlet:SPEC:102 | 10 | 8 | A server should be able to replace an application with a new version without restarting the container. When an application is replaced, the container should provide a robust method for preserving session data within that application. | false |
| true | technology | active | false |
| Servlet:SPEC:103 | 10 | 9.1 | A web application must be able to specify that when errors occur other resources in the application are used to provide the content body of the error response. | true |
| false | technology | active | true |
| Servlet:SPEC:104 | 10 | 9.1 | If the location of the error handler is a servlet or JSP page, then: | true |
| false | technology | active | true |
| Servlet:SPEC:104.1 | 10 | 9.1 | The original unwrapped request and response objects created by the container are passed to the servlet or JSP page. | true |
| false | technology | active | true |
| Servlet:SPEC:104.2 | 10 | 9.1 | The response setStatus method is disabled and ignored if called. | true |
| false | technology | removed | true |
| Servlet:SPEC:104.3 | 10 | 9.1 | The request path and attributes are set as if a RequestDispatcher.forward to the error resource has been performed. | true |
| false | technology | active | true |
| Servlet:SPEC:104.3.1 | 10 | 9.1 | The request attribute 'jakarta.servlet.error.status_code' of type 'java.lang.Integer' will be set containing the HTTP status code of the error condition. | true |
| false | technology | active | true |
| Servlet:SPEC:104.3.2 | 10 | 9.1 | The request attribute 'jakarta.servlet.error.exception_type' of type 'java.lang.Class' will be set if the error page was invoked due to an uncaught exception. | true |
| false | technology | active | true |
| Servlet:SPEC:104.3.3 | 10 | 9.1 | The request attribute 'jakarta.servlet.error.message' of type 'java.lang.String' will be set if the error page was invoked due to an uncaught exception. | true |
| false | technology | active | true |
| Servlet:SPEC:104.3.4 | 10 | 9.1 | The 'jakarta.servlet.error.exception' attribute of type 'java.lang.Throwable' will be set if the error page was invoked due to an uncaught exception. | true |
| false | technology | active | true |
| Servlet:SPEC:104.3.5 | 10 | 9.1 | The 'jakarta.servlet.error.request_uri' attribute of type 'java.lang.String' will contain the URI of the offending resource. | true |
| false | technology | active | true |
| Servlet:SPEC:104.3.6 | 10 | 9.1 | The 'jakarta.servlet.error.servlet_name' attribute of type 'java.lang.String' will contain the logical name of the servlet in which the error occurred. | true |
| false | technology | active | true |
| Servlet:SPEC:105 | 10 | 9.2 | If the sendError method is called on the response, the container consults the list of error page declarations for the web application that use the status-code syntax and attempts a match. If there is a match, the container returns the resource as indicated by the location entry. | true |
| false | technology | active | true |
| Servlet:SPEC:106 | 10 | 9.2 | In the case where the container is matching error pages based on the exception-type element, a match results in the container returning the resource indicated in the location entry. The closest match in the class hierarchy wins. | true |
| false | technology | active | true |
| Servlet:SPEC:107 | 10 | 9.2 | If no error-page declaration containing an exception-type fits using the class-hierarchy match, and the exception throws is a ServletException or subclass thereof the container extraces the wrapped exception, as defined by the ServletException.getRootCause method and a second pass is made of the error page declarations, again attempting the match against the error page declearations, but using the wrapped exception. | true |
| false | technology | active | true |
| Servlet:SPEC:108 | 10 | 9.2 | Error-page declarations using the exception-type element in the deployment descriptor must be unique up to the class name of the exception type. | true |
| false | technology | active | false |
| Servlet:SPEC:109 | 10 | 9.2 | Error page declarations using the status-code elements must be unique in the deployment descriptor up to the status-code. | true |
| false | technology | active | true |
| Servlet:SPEC:110 | 10 | 9.2 | The error page mechanism does not intervene when errors occur when invoked using the RequestDispatcher or Filter.doFilter method. In this way, a filter or servlet using the RequestDispatcher has the opportunity to handle errors generated. | true |
| false | technology | active | true |
| Servlet:SPEC:111 | 10 | 9.2 | If a servlet generates an error that is not handled by the error page mechanism as described above, the container must ensure to send a response with status 500. | true |
| false | technology | active | true |
| Servlet:SPEC:112 | 10 | 9.2 | The default servlet and container will use the sendError method to send 4xx and 5xx responses so that the error mechanism may be invoked. | true |
| false | technology | active | true |
| Servlet:SPEC:113 | 10 | 9.2 | The default servlet and container will use the setStatus method to send 2xx and 3xx responses to bypass the error mechanism | true |
| false | technology | active | true |
| Servlet:SPEC:114 | 10 | 10 | If a web container receives a valid partial request, the web container must examine the welcome files list, which is an ordered list of partial URLs, with no leading or trailing slash, and append the each welcome file to the partial URI in the order it was defined to find a match. The web container must send the request to the first resource in the WAR that matches. | true |
| false | technology | active | true |
| Servlet:SPEC:115 | 10 | 10 | If no welcome file match is found, the container may handle the request as it sees fit. | true |
| true | technology | active | false |
| Servlet:SPEC:116 | 10 | 11 | Jakarta EE compliant servlet containers are required to support the following elements of the web deployment descriptor for specifying information allowing a servlet to obtain references to resources and enterprise beans. The deployment elements that contain this information are: | true |
| false | platform | active | true |
| Servlet:SPEC:116.1 | 10 | 11 | env-entry | true |
| false | platform | active | true |
| Servlet:SPEC:116.2 | 10 | 11 | ejb-ref | true |
| false | platform | active | true |
| Servlet:SPEC:116.3 | 10 | 11 | ejb-local-ref | true |
| false | platform | active | true |
| Servlet:SPEC:116.4 | 10 | 11 | resource-env-ref | true |
| false | platform | active | true |
| Servlet:SPEC:116.5 | 10 | 11 | resource-ref | true |
| false | platform | active | true |
| Servlet:SPEC:117 | 10 | 11 | If the standalone container does not support these lookup facilities, the container should provide a warning upon deployment of an application that has dependencies on such resources. | false |
| false | technology | active | false |
| Servlet:SPEC:118 | 10 | 11 | Servlet containers that are part of a Jakarta EE technology compliant implementation must support lookups of such objects and calls made to those objects when performed on a thread managed by the servlet container. | true |
| false | platform | active | true |
| Servlet:SPEC:119 | 10 | 11 | Such servlet containers should support this lookup behavior when performed on threads created by the developer, but are not required to do so. | false |
| false | technology | active | false |
| Servlet:SPEC:182 | 10 | 12 | <![CDATA[When a web application is deployed into a container, the following steps must be performed, in this order, before the web application begins processing client requests.
1. Instantiate an instance of each event listener identified by a <listener> element in the deployment descriptor.
2. For instantiated listener instances that implement ServletContextListener, call the contextInitialized() method.
3. Instantiate an instance of each filter identified by a <filter>> element in the deployment descriptor and call each filter instances init() method.
4. Instantiate an instance of each servlet identified by a <servlet> element that includes a <load-on-startup> element in the order defined by the load-onstartup element values, and call each servlet instances init() method.]]>
| true |
| false | technology | active | true |
| Servlet:SPEC:201 | 10 | 13 | A web application is NOT required to contain a web.xml if it does NOT contain any Servlet,
Filter, or Listener components. In other words an application containing only static files
or JSP pages does not require a web.xml to be present.
| true |
| false | platform | active | true |
| Servlet:SPEC:120 | 11 | 3.1 | Each listener class specified in the deployment descriptor must have a public constructor taking no arguments. | true |
| false | technology | active | false |
| Servlet:SPEC:121 | 11 | 3.2 | Listeners will be invoked in the order that they are defined in the deployment descriptor. | true |
| false | technology | removed | true |
| Servlet:SPEC:122 | 11 | 3.3 | The Web container creates an instance of each listener class and registers it
for event notifications prior to the processing of the first request by the application
| true |
| false | technology | active | false |
| Servlet:SPEC:123 | 11 | 3.3 | The Web container registers the listener instances according to the interfaces
they implement and the order in which they appear in the deployment descriptor.
| true |
| false | technology | active | true |
| Servlet:SPEC:124 | 11 | 3.3 | During Web application execution, listeners corresponding to given events are
invoked in the order of their registration.
| true |
| false | technology | active | true |
| Servlet:SPEC:125 | 11 | 3.4 | On application shutdown, listeners are notified in reverse order to their declarations with notifications to session listeners preceeding notifications to context listeners. Session listeners must be notified of session invalidations prior to context listeners being notified of application shutdown. | true |
| false | technology | active | false |
| Servlet:SPEC:126 | 11 | 5 | The container is required to complete instantiation of the listener classes in a web application prior to the start of execution of the first request into the application. | true |
| false | technology | active | true |
| Servlet:SPEC:127 | 11 | 5 | The container must maintain a reference to each listener instance until the last request is serviced for the web application. | true |
| false | technology | active | false |
| Servlet:SPEC:128 | 11 | 6 | The container must allow unhandled exceptions to be handled by the error page mechanism described in Section SRV.9.9, "Error Handling". If there is no error page specified for those exceptions, the container must ensure to send a response back with status 500. In this case no more listeners under that event are called. | true |
| false | technology | active | true |
| Servlet:SPEC:129 | 11 | 6 | In cases where it is not possible to handle an Exception in application code (ex. an Exception occuring during initialization of a ContextListener), the container may response to all subsequent requests with an HTTP status code of 500 to indicate application error. | false |
| false | technology | active | false |
| Servlet:SPEC:130 | 11 | 7 | In distributed web containers, HttpSession instances are scoped to the particular VM services session requests, and the ServletContext object is scoped to the web container's VM. | false |
| false | technology | active | false |
| Servlet:SPEC:131 | 11 | 7 | Distributed containers are not required to propogate either servlet context events or HttpSession events to other VMs. | false |
| false | technology | active | false |
| Servlet:SPEC:132 | 11 | 7 | Listener class instances are scoped to one per deployment descriptor declaration per Java virtual machine. | true |
| false | technology | active | false |
| Servlet:SPEC:133 | 12 | 1 | Upon receipt of a client request, the Web container determines the Web application to which to forward it. The Web application selected must have the longest context path that matches the start of the request URL. The matched part of the URL is the context path when mapping to servlets. | true |
| false | technology | active | true |
| Servlet:SPEC:134 | 12 | 1 | The Web container next must locate the servlet to process the request using the path mapping procedure described below. The path used for mapping to a servlet is the request URL from the request object minus the context path and the path parameters. The URL path mapping rules below are used in order. The first successful match is used with no further matches attempted | true |
| false | technology | active | true |
| Servlet:SPEC:134.1 | 12 | 1 | The container will try to find an exact match of the path of the request to the path of the servlet. A successful match selects the servlet. | true |
| false | technology | active | true |
| Servlet:SPEC:134.2 | 12 | 1 | The container will recursively try to match the longest path-prefix: This is done by stepping down the path tree a directory at a time, using the '/' character as a path separator. The longest match determines the servlet selected. | true |
| false | technology | active | true |
| Servlet:SPEC:134.3 | 12 | 1 | If the last segment in the URL path contains an extension (e.g. .jsp), the servlet container will try to match a servlet that handles requests for the extension. An extension is defined as the part of the last segment after the last '.' character. | true |
| false | technology | active | true |
| Servlet:SPEC:134.4 | 12 | 1 | If neither the previous three rules result in a servlet match, the container will attempt to serve content appropriate for the resource requested. If a "default" servlet is defined for the applications, it will be used. | true |
| false | technology | active | true |
| Servlet:SPEC:134.5 | 12 | 1 | The container must use case-sensitive string comparisons for matching. | true |
| false | technology | active | true |
| Servlet:SPEC:220 | 12 | 2 | In the Web application deployment descriptor, the following syntax is used to define mappings | true |
| false | technology | active | true |
| Servlet:SPEC:220.1 | 12 | 2 | A string beginning with a / character and ending with a /* suffix is used for path mapping. | true |
| false | technology | active | true |
| Servlet:SPEC:220.2 | 12 | 2 | A string beginning with a *. prefix is used as an extension mapping. | true |
| false | technology | active | true |
| Servlet:SPEC:220.3 | 12 | 2 | The empty string ("") is a special URL pattern that exactly maps to the application's context root, i.e., requests of the form http://host:port/<contextroot>/. In this case the path info is / and the servlet path and context path is empty string "". | true |
| false | technology | active | true |
| Servlet:SPEC:220.4 | 12 | 2 | A string containing only the character / indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null. | true |
| false | technology | active | true |
| Servlet:SPEC:220.5 | 12 | 2 | All other strings are used for exact matches only. | true |
| false | technology | active | true |
| Servlet:SPEC:135 | 12 | 2.1 | If the container has an internal JSP container, the *.jsp extension is mapped to it, allowing JSP pages to be executed on demand. | true |
| false | platform | active | true |
| Servlet:SPEC:136 | 12 | 2.1 | A servlet container is allowed to make other implicit mappings as long as explicit mappings take precedence. | false |
| false | technology | active | false |
| Servlet:SPEC:137 | 13 | 2 | Declarative security constraints are not applied when a servlet uses the RequestDispatcher to invoke a static resource or servlet using a forward or an include. | true |
| false | platform | active | true |
| Servlet:SPEC:138 | 13 | 3 | The isUserInRole method uses the security-role-ref element when determining the return value of the call. If no security-role-ref element matching a security-role element has been declared, the container must default to checking the role-name element against the list of security-role elements for the web applications. | true |
| false | platform | active | true |
| Servlet:SPEC:290 | 13 | 4.1 | Servlet containers MUST support the use of the @ServletSecurity
annotation on classes (and subclasses thereof) that implement
the jakarta.servlet.Servlet interface.
| true |
| false | platform | active | true |
| Servlet:SPEC:291 | 13 | 4.1 | The @HttpConstraint annotation is used within the @ServletSecurity
annotation to represent the security constraint to be applied to all
HTTP protocol methods for which a corresponding @HttpMethodConstraint
does NOT occur within the @ServletSecurity annotation.
| true |
| false | platform | active | true |
| Servlet:SPEC:292 | 13 | 4.1 | At most one instance of the @ServletSecurity annotation may occur
on a Servlet implementation class, and the @ServletSecurity annotation
MUST NOT be specified on (that is, targeted to) a Java method.
| true |
| false | platform | active | false |
| Servlet:SPEC:293 | 13 | 4.1 | When one or more @HttpMethodConstraint annotations are defined within
a @ServletSecurity annotation, each @HttpMethodConstraint defines the
security-constraint that applies to the HTTP protocol method identified
within the @HttpMethodConstraint. The encompassing @ServletSecurity
annotation defines the security-constraint that applies to all HTTP
protocol methods other than those for which a corresponding
@HttpMethodConstraint is defined within the @ServletSecurity annotation.
| true |
| false | platform | active | true |
| Servlet:SPEC:294 | 13 | 4.1 | When a security-constraint in the portable deployment descriptor
includes a url-pattern that is an exact match for a pattern mapped
to a class annotated with @ServletSecurity, the annotation must
have no effect on the constraints enforced by the Servlet container
on the pattern.
| true |
| false | platform | active | true |
| Servlet:SPEC:295 | 13 | 4.1 | When metadata-complete=true is defined for a portable deployment
descriptor, the @ServletSecurity annotation does not apply to any
of the url-patterns mapped to (any servlet mapped to) the annotated
class in the deployment descriptor.
| true |
| false | platform | active | true |
| Servlet:SPEC:296 | 13 | 4.1.2 | The enforcement by Servlet containers, of the @ServletSecurity
annotation must be equivalent in effect to enforcement, by the
container, of the security-constraint elements resulting from
the mapping defined in this section.
| true |
| false | platform | active | true |
| Servlet:SPEC:297 | 13 | 4.1.2 | The @ServletSecurity annotation is used to define one
method-independent @HttpConstraint followed by a list of zero
or more @HttpMethodConstraint specifications. The method-independent
constraint is applied to all HTTP methods for which no HTTP
method-specific constraint has been defined.
| true |
| false | platform | active | true |
| Servlet:SPEC:298 | 13 | 4.1.2 | When no @HttpMethodConstraint elements are included, a
@ServletSecurity annotation corresponds to a single
security-constraint element containing a web-resource-collection
that contains no http-method elements, and thus pertains to all
HTTP methods.
| true |
| false | platform | active | true |
| Servlet:SPEC:139 | 13 | 5 | A servlet container enforces declarative or programmatic security for the principal associated with an incoming request based on the security attributes of the principal. This may happen in either of the following ways: | true |
| false | platform | active | true |
| Servlet:SPEC:139.1 | 13 | 5 | A deployer has mapped a security role to a user group in the operational environment. The user group to which the calling principal belongs is retrieved from its security attributes. The principal is in the security role only if the principals user group matches the user group to which the security role has been mapped by the deployer. | true |
| false | platform | active | true |
| Servlet:SPEC:139.2 | 13 | 5 | A deployer has mapped a security role to a principal name in a security policy domain. In this case, the principal name of the calling principal is retrieved from its security attributes. The principal is in the security role only if the principal name is the same as a principal name to which the security role was mapped. | true |
| false | platform | active | true |
| Servlet:SPEC:140 | 13 | 6.1 | HTTP Basic Authentication is required to be supported by servlet containers. | true |
| false | platform | active | true |
| Servlet:SPEC:141 | 13 | 6.2 | HTTP Digest Authentication is not a required authentication mechanism for servlet containers. | false |
| false | platform | active | false |
| Servlet:SPEC:142 | 13 | 6.3 | Form based authentication allows the customization of the login screen. | true |
| false | platform | active | false |
| Servlet:SPEC:142.1 | 13 | 6.3 | The login form used for form based authentication must contain fields for entering a username and a password. These fields must be j_username and j_password, respectively. | true |
| false | platform | active | true |
| Servlet:SPEC:142.2 | 13 | 6.3 | The login form used by the container can be specified within the deployment descriptor. | true |
| false | platform | active | true |
| Servlet:SPEC:142.3 | 13 | 6.3 | An error page can be specified in the deployment descriptor which will be returned on failed form based authentication attempts. | true |
| false | platform | active | true |
| Servlet:SPEC:142.4 | 13 | 6.3 | The authentication process for form based login: | true |
| false | platform | active | false |
| Servlet:SPEC:142.4.1 | 13 | 6.3 | The login form associated with the security constraint is sent to the client and the URL path triggering the authentication is stored by the container. | true |
| false | platform | active | true |
| Servlet:SPEC:142.4.2 | 13 | 6.3 | The container attempts to authenticate the user using the information from the form. | true |
| false | platform | active | true |
| Servlet:SPEC:142.4.3 | 13 | 6.3 | If authentication fails, the error page is returned using either a forward or a redirect, and the status code of the response is set to 200. | true |
| false | platform | active | true |
| Servlet:SPEC:142.4.4 | 13 | 3.1 | If authentication succeeds, the authenticated user's principal is check to see if it is in an authroized role for accessing the resource. | true |
| false | platform | active | true |
| Servlet:SPEC:142.4.5 | 13 | 3.1 | If the user is authorized, the client is redirected to the resource using the stored URL path. | true |
| false | platform | active | true |
| Servlet:SPEC:142.5 | 13 | 6.3.1 | The action of the login form must always be j_security_check. | true |
| false | platform | active | true |
| Servlet:SPEC:142.6 | 13 | 6.3.1 | If the form based login is invoked because of an HTTP request, the original request parameters must be preserved by the container for use if on successful authentication, it redirects the call to the requested resource. | true |
| false | platform | active | true |
| Servlet:SPEC:142.7 | 13 | 6.3.1 | If the user is authenticated using form login and has created an HTTP session, the timeout or invalidation of that session leads to the user being logged out in the sense that subsequent requests must cause the user to be re-authenticated. | true |
| false | platform | active | true |
| Servlet:SPEC:143 | 13 | 6.4 | Servlet containers that are not Jakarta EE technology compliant are not required to support HTTPS protocol/authentication. | false |
| false | platform | active | false |
| Servlet:SPEC:144 | 13 | 7 | Servlet containers are required to track authentication information at the container level rather than at the web application level. | true |
| false | platform | active | false |
| Servlet:SPEC:145 | 15 | 3.1 | A security identity, or principal, must always be provided for use in a call to an enterprise bean. | true |
| true | platform | active | false |
| Servlet:SPEC:146 | 15 | 3.1 | The default mode in calls to enterprise beans from web applications is for the security identity of a web user to be propagated to the Jakarta Enterprise Beans container. | true |
| true | platform | active | false |
| Servlet:SPEC:147 | 15 | 3.1 | If a container supports calls to Jakarta Enterprise Beans' containers are required to support access to web resources by clients that have not authenticated themselves to the container through the use of the run-as element of the deployment descriptor. The container will use this identity when propagating the call from the web layer to the Jakarta Enterprise Beans layer. | true |
| false | platform | active | false |
| Servlet:SPEC:147.1 | 15 | 3.1 | The security role propagated through the run-as element must be a security role defined in the deployment descriptor of the web application. | true |
| true | platform | active | false |
| Servlet:SPEC:148 | 15 | 3.1 | Web containers running as part of a Jakarta EE platform, the use of run-as elements must be supported both for calls to Jakarta Enterprise Beans components within the same Jakarta EE application, and for calls to Jakarta Enterprise Beans components deployed in other Jakarta EE applications. | true |
| false | platform | active | false |
| Servlet:SPEC:149 | 13 | 8 | If a request is issued against a set of protected resources the user who made the request must be a member of at least one of the named roles to be permitted to perform the contrained requests. | true |
| false | platform | active | true |
| Servlet:SPEC:150 | 13 | 8 | The special role name "*" is a shorthand for all role names defined in the deployment descriptor. | true |
| false | platform | active | true |
| Servlet:SPEC:151 | 13 | 8 | An auth constraint that names no roles indicates that access ot the contrained resources must not be permitted under any circumstances. | true |
| false | platform | active | true |
| Servlet:SPEC:152 | 13 | 8 | A user data constraint establishes a requirement that the constrained requests be received over a protected transport layer connection. | true |
| false | platform | active | false |
| Servlet:SPEC:152.1 | 13 | 8 | A transport guarantee of INTEGRAL is used to establish a requirement for content integrity. | true |
| false | platform | active | false |
| Servlet:SPEC:152.2 | 13 | 8 | A transport guarantee of CONFIDENTIAL is used to establish a requirement for confidentiality. | true |
| false | platform | active | false |
| Servlet:SPEC:152.3 | 13 | 8 | A transport guarantee of NONE indicates that the container must accept the constrained requests when received on any connection including unprotected ones. | true |
| false | platform | active | true |
| Servlet:SPEC:153 | 13 | 8 | If no auth-constraing applies to a request, the container must accept the request without requiring user authentication. | true |
| false | platform | active | true |
| Servlet:SPEC:154 | 13 | 8.1 | When a url-pattern and http-method pair occurs in multiple security constraints, the applicable constraints (on the pattern and the method) are defined by combining the individual constraints. | true |
| false | platform | active | true |
| Servlet:SPEC:154.1 | 13 | 8.1 | A security constraint that does not contain an auth constraint shall combine with auth constraints that name or imply roles to allow unauthenticated access. | true |
| false | platform | active | true |
| Servlet:SPEC:154.2 | 13 | 8.1 | The special case of an auth constraint that names no roles shall combine with any other constraints to override their affects and cause access to be precluded. | true |
| false | platform | active | true |
| Servlet:SPEC:154.3 | 13 | 8.1 | The combination of user-data constraints that apply to a common usr-pattern and http-method shall yield the union of connection types accepted by the individual constraints as acceptable connection types. | true |
| false | platform | active | false |
| Servlet:SPEC:154.4 | 13 | 8.1 | A security constraint that does not contain a user-data constraint shall combine with other user-data constraints to cause the unprotected connection type to be an accepted connection type. | true |
| false | platform | active | true |
| Servlet:SPEC:155 | 13 | 8.3 | When a Servlet container receives a request, it shall use the url pattern matching algorithm to select the constraints, if any, defined that is the best match to the request URI | true |
| false | platform | active | true |
| Servlet:SPEC:156 | 13 | 8.3 | If no security contraint can be matched between the defined contraints and the request URI, the container will accept the request. | true |
| false | platform | active | true |
| Servlet:SPEC:157 | 13 | 8.3 | If a constraint match is found based on the request URI, the container shall determine if the HTTP method of the request is constrained, if it's not, then the constrained request will be accepted. | true |
| false | platform | active | true |
| Servlet:SPEC:158 | 13 | 8.3 | If the HTTP method is contrained, then the method used for the request must match what is acceptable for the constraint in order for the request to be accepted. | true |
| false | platform | active | true |
| Servlet:SPEC:159 | 13 | 8.3 | If the characteristics of the connection on which the request was received must satisfy at least one of the supported connection types defined by the constraints. If this rule is not satisfied, the container shall reject the request and redirect it to the HTTPS port. | true |
| false | platform | active | true |
| Servlet:SPEC:159.1 | 13 | 8.3 | As an optimization, a container should reject the connection request if it doesn't match the constrained connection types and return a 403 (SC_FORBIDDEN) status code if it knows that access will ultimately be precluded (by an auth constraint naming with no roles). | false |
| false | platform | active | false |
| Servlet:SPEC:160 | 13 | 8.3 | If a constraint naming defined no roles, any attempted requests will result in a 403 (SC_FORBIDDEN). | true |
| false | platform | active | true |
| Servlet:SPEC:161 | 13 | 8.3 | If access is restricted to permitted roles and the request has not been authenticated, the request shall be rejected as unauthorized and a 401 (SC_UNAUTHORIZED) status code shall be returned to cause authentication. | true |
| false | platform | active | true |
| Servlet:SPEC:162 | 13 | 8.3 | If access is restricted to permitted roles and the authentication identity of the request is not a member of any of these roles, the request shall be rejected as forbidden and a 403 (SC_FORBIDDEN) status code shall be returned to the user. | true |
| false | platform | active | true |
| Servlet:SPEC:309 | 13 | 8.4.2 |
When the deny-uncovered-http-methods flag is set in the web.xml of an application, the container
must deny any HTTP protocol method when it is used with a request URL for which the HTTP method
is uncovered at the combined security constraint that applies to the url-pattern that is the best
match for the request URL. The denied request shall be rejected as forbidden and a 403 (SC_FORBIDDEN)
status code shall be returned.
| true |
| false | platform | active | true |
| Servlet:SPEC:310 | 13 | 8.4.2 |
When an applications security configuration contains no uncovered methods, the
deny-uncovered-http-methods flag must have no effect on the effective security
configuration of the application.
| true |
| false | platform | active | true |
| Servlet:SPEC:163 | 13 | 10 | If a developer creates a session while a user is not authenticated, and the container then authenticates the user, the session visible to developer code after login must be the same session object that was created prior to login occurring so that there is no loss of session information. | true |
| false | platform | active | true |
| Servlet:SPEC:164 | 13 | 10 | For all authentication methods in both non-single signon and single signon containers, logout is caused by one of the following situations: | true |
| false | platform | removed | true |
| Servlet:SPEC:164.1 | 13 | 10 | Invalidation of the session. If this occurs, getUserPrincipal will return a null value. | true |
| false | platform | removed | true |
| Servlet:SPEC:164.2 | 13 | 10 | Session timeouts. If this occurs, getUserPrincipal will return a null value. | true |
| false | platform | removed | true |
| Servlet:SPEC:164.3 | 13 | 10 | An explicit call to HttpSession.invalidateAll. If this occurs, getUserPrincipal will return a null value. | true |
| false | platform | removed | true |
| Servlet:SPEC:164.4 | 13 | 10 | An explicit call to HttpSession.logout.If this occurs, getUserPrincipal will return a null value. | true |
| false | platform | removed | true |
| Servlet:SPEC:165 | 13 | 10 | For non-single signon containers, a session invalidating has no effect on login state or session state in other web applications. | true |
| false | platform | active | false |
| Servlet:SPEC:166 | 13 | 10 | For single signon containers, logout causes all other active sessions associated with the current user to be invalidated. | true |
| false | platform | active | false |
| Servlet:SPEC:167 | 13 | 10 | Invalidation or timeout of an individual session causes the termination of that session, but does not cause a logout unless it is the last session for this user, which means that a container is allowed to start a new session for one or more web applications without re-authenticating the user. | false |
| false | platform | removed | false |
| Servlet:SPEC:168 | 14 | 2 | Servlet 2.5 web containers may use schema to validate the structure of a deployment descriptor. | false |
| false | technology | active | false |
| Servlet:SPEC:169 | 14 | 1 | The deployment-extension element provides the ability to inject application or framework specific configuration information directly into the deployment descriptor. | true |
| true | technology | removed | false |
| Servlet:SPEC:169.1 | 14 | 1 | If a container uses schema to validate a deployment descriptor, any new content injected into deployment-extension elements as described below will not be validated by the web container. | false |
| false | technology | removed | false |
| Servlet:SPEC:169.2 | 14 | 1 | Deployment extensions are only valid within the top level web-app element or within servlet elements. | true |
| false | technology | removed | false |
| Servlet:SPEC:169.3 | 14 | 1.1 | Servlet 2.5 containers are required to raise an exception if they do not recognize an extension within a deployment descriptor where the mustUnderstand attribute is 'true'. | true |
| false | technology | removed | false |
| Servlet:SPEC:169.4 | 14 | 1.1 | Servlet 2.5 containers are not required to attempt to process extended deployment information where the nustUnderstand attribute is set to 'false'. | false |
| false | technology | removed | false |
| Servlet:SPEC:170 | 14 | 1 | Security information which may appear in the deployment descriptor is not required to be supported unless the servlet container is part of an implementation of the Jakarta EE specification. | true |
| false | platform | active | true |
| Servlet:SPEC:193 | 15 | 4.1 | The following additional elements exist in the Web application deployment descriptor to meet the requirements of Web containers that are JSP pages enabledor part of a Jakarta EE application server. They are not required to be supported by containers wishing to support only the servlet specification: | true |
| false | platform | active | true |
| Servlet:SPEC:171 | 15 | 4.1 | jsp-config | true |
| false | platform | active | true |
| Servlet:SPEC:172 | 15 | 4.1 | Syntax for looking up JNDI objects(env-entry, ejb-ref, ejb-local-ref, resource-ref, resource-env-ref) | true |
| false | platform | active | true |
| Servlet:SPEC:193.1 | 15 | 4.1 | Syntax for specifying the message destination (message-destination, message-destination-ref) | true |
| false | platform | active | true |
| Servlet:SPEC:193.2 | 15 | 4.1 | Reference to a Web service (service-ref) | true |
| false | platform | active | true |
| Servlet:SPEC:174 | 14 | 2 | Web containers must remove all leading and trailing
whitespace, which is defined as "S(whitespace)" in XML 1.0 (http://www.w3.org/TR/2000/WD-xml-
2e-20000814), for the element content of the text nodes of a deployment descriptor.
| true |
| false | technology | removed | true |
| Servlet:SPEC:175 | 14 | 2 | The containers and tools that are
part of Jakarta EE technology-compliant implementation are required to validate
deployment descriptor against the XML schema for structural correctness.
| true |
| false | technology | active | true |
| Servlet:SPEC:176 | 14 | 2 | It is recommended that Web containers and tools that
manipulate Web applications provide a level of semantic checking. For example, it
should be checked that a role referenced in a security constraint has the same
name as one of the security roles defined in the deployment descriptor.
| false |
| false | technology | active | true |
| Servlet:SPEC:10176 | 14 | 2 | The sub elements under web-app can be in an arbitrary
order.
| true |
| false | technology | active | true |
| Servlet:SPEC:11276 | 14 | 2 | The multiplicity
of the elements distributable, session-config, welcome-file-list, jspconfig,
login-config, and locale-encoding-mapping-list is "0 or more."
| true |
| false | technology | active | false |
| Servlet:SPEC:11276.1 | 14 | 2 | Containers must inform the developer
with a descriptive error message when the deployment descriptor contains
more than one element of session-config, jsp-config, and login-config.
| true |
| false | technology | active | false |
| Servlet:SPEC:11276.2 | 14 | 3 | The deployment descriptor instance
file must not contain multiple elements of session-config,
jsp-config, and login-config.
| true |
| false | technology | active | false |
| Servlet:SPEC:11276.3 | 14 | 2 | The container must concatenate the items
in welcome-file-list and locale-encoding-mapping-list when there are multiple occurrences.
| true |
| false | technology | active | true |
| Servlet:SPEC:11276.4 | 14 | 2 | The multiple
occurrence of distributable must be treated exactly in the same way as the
single occurrence of distributable.
| true |
| false | technology | active | true |
| Servlet:SPEC:11276 | 14 | 2 | URI paths specified in the deployment descriptor are
assumed to be in URLdecoded form.
| true |
| false | technology | active | false |
| Servlet:SPEC:11276.1 | 14 | 2 | The containers must inform the developer
with a descriptive error message when URL contains CR(#xD) or LF(#xA).
| true |
| false | technology | active | false |
| Servlet:SPEC:11276.2 | 14 | 2 | The containers must
preserve all other characters including whitespace in URL.
| true |
| false | technology | active | true |
| Servlet:SPEC:177 | 14 | 2 | Containers must attempt to canonicalize paths in present in the deployment descriptor. | false |
| false | technology | active | true |
| Servlet:SPEC:178 | 14 | 3 | Paths beginning or resolving to paths that begin with ".." are not valid paths in the deployment descriptor. | true |
| false | technology | active | false |
| Servlet:SPEC:179 | 14 | 3 | Elements whose valus is an enumerated type must be treated in a case sensitive manner. | true |
| false | technology | active | false |
| Servlet:SPEC:214 | 14 | 4 |
Servlet containers are required to support the use of these annotations
within classes that extend the jakarta.servlet.http.HttpServlet abstract
class.
| true |
| false | technology | removed | true |
| Servlet:SPEC:215 | 14 | 4 |
When specified on a class target, these annotations apply to all requests
processed by the public service method of the HttpServlet implementation class.
| true |
| false | technology | removed | true |
| Servlet:SPEC:216 | 14 | 4 |
When an annotation is specified at both the class and method level, the method
targeted annotation overrides that on the class (for the method).
| true |
| false | technology | removed | true |
| Servlet:SPEC:217 | 14 | 4 |
When the metadata-complete attribute is set in the portable deployment
descriptor, the annotations described in this section have no effect on
the access control policy enforced by the container on behalf of the
corresponding web module or web fragment.
| true |
| false | technology | removed | true |
| Servlet:SPEC:218 | 14 | 4 |
When a security-constraint in the portable deployment descriptor
includes a url-pattern that matches a request URL, the security
annotations described in this section have no effect on the access
policy that applies to the request URL.
| true |
| false | technology | removed | true |
| Servlet:SPEC:219 | 14 | 4 |
When none of these annotations have been assigned to the class and method
targets corresponding to a request, the access policy that is applied to
the request is established by the applicable security constraints, if any,
in the corresponding portable deployment descriptor.
| true |
| false | technology | removed | true |
| Servlet:SPEC:184 | 15 | 2 | Jakarta EE technology-compliant containers are required to provide a mechanism by which a deployer can learn about what jar file containing resources and code are available for the Web application. | true |
| false | platform | active | false |
| Servlet:SPEC:185 | 15 | 2 | Containers should provide a convenient procedure for editing and configuring library files or extensions. | false |
| true | platform | active | false |
| Servlet:SPEC:186 | 15 | 2.1 | Servlet containers that are part of a Jakarta EE product should not
allow the application to override Java SE or Jakarta EE platform classes,
such as those in the java.* and javax.* namespaces,
that either Java SE or Jakarta EE do not allow to be modified.
| true |
| false | platform | active | true |
| Servlet:SPEC:187 | 15 | 3.1 | A security identity, or principal, must always be provided for use in a call to an enterprise bean. | true |
| true | platform | active | true |
| Servlet:SPEC:188 | 15 | 3.1 | The default mode in calls to enterprise beans from web applications is
for the security identity of a web user to be propagated to the Jakarta Enterprise Beans container.
| true |
| true | platform | active | true |
| Servlet:SPEC:189 | 15 | 3.1 | web containers are required to allow web users that are not known to the web container
or to the Jakarta Enterprise Beans container to make calls:
| true |
| false | platform | active | true |
| Servlet:SPEC:189.1 | 15 | 3.1 | Web containers are required to support access to web resources by clients
that have not authenticated themselves to the container.
This is the common mode of access to web resources on the Internet.
| true |
| true | platform | active | true |
| Servlet:SPEC:189.2 | 15 | 3.1 | Application code may be the sole processor of signon and
customization of data based on caller identity.
| true |
| true | platform | active | false |
| Servlet:SPEC:190 | 15 | 3.1 | a web application deployment descriptor may specify a run-as element.
When a run-as role is specified for a Servlet, the Servlet container must
propagate a principal mapped to the role as the security identity in any call from the
Servlet to an Enterprise Beans, including calls originating from the Servlet's init and destroy
methods. The security role name must be one of the security role names defined for
the web application.
| true |
| false | platform | active | true |
| Servlet:SPEC:191 | 15 | 3.1 | For web containers running as part of a Jakarta EE platform,
the use of run-as elements must be supported both for calls to Jakarta Enterprise Beans components within the same Jakarta EE application,
and for calls to Jakarta Enterprise Beans components deployed in other Jakarta EE applications.
| true |
| false | platform | active | true |
| Servlet:SPEC:194 | 15 | 4.2 | Web containers may choose to support running components written to implement a Web service endpoint
as defined by the JAX-RPC and/or JAX-WS specifications.
| false |
| false | technology | active | true |
| Servlet:SPEC:173 | 15 | 4.2 | Web containers embedded in a JavaEE conformant implementation are required to support JAX-RPC and JAX-WS web service components. | true |
| false | platform | active | true |
| Servlet:SPEC:173.1 | 15 | 4.2 | JSR-109 [http://jcp.org/jsr/detail/109.jsp] defines the model for packaging a Web service interface
with its associated WSDL description and associated classes.
| true |
| false | platform | active | true |
| Servlet:SPEC:173.2 | 15 | 4.2 | It(JSR-109) defines a mechanism for JAX-WS and JAX-RPC enabled Web containers to link to a component that implements this Web service. | true |
| false | platform | active | true |
| Servlet:SPEC:173.3 | 15 | 4.2 | JAX-WS and JAX-RPC enabled Web containers must support the developer
in using the Web deployment descriptor
to define the following information for the endpoint implementation component,
using the same syntax as for HTTP Servlet components using the servlet element.
The child elements are are used to specify endpoint information in the following way:
| true |
| false | platform | active | true |
| Servlet:SPEC:173.3.1 | 15 | 4.2 | the servlet-name element defines a logical name which may be used
to locate this endpoint description among the other Web components in the WAR
| true |
| false | platform | active | true |
| Servlet:SPEC:173.3.2 | 15 | 4.2 | the servlet-class element provides the fully qualified Java class name of this endpoint implementation | true |
| false | platform | active | true |
| Servlet:SPEC:173.3.3 | 15 | 4.2 | the description element(s) may be used to describe the component and may be displayed in a tool | false |
| false | platform | active | true |
| Servlet:SPEC:173.3.4 | 15 | 4.2 | the load-on-startup element specifies the order in which the component is initialized relative to other Web components in the Web container | true |
| false | platform | active | true |
| Servlet:SPEC:173.3.5 | 15 | 4.2 | the security-role-ref element may be used to test whether the authenticated user is in a logical security role | false |
| false | platform | active | true |
| Servlet:SPEC:173.3.6 | 15 | 4.2 | the run-as element may be used to override the identity propagated to Jakarta Enterprise Beans called by this component | true |
| false | platform | active | true |
| Servlet:SPEC:173.4 | 15 | 4.2 | Any servlet initialization parameters defined by the developer for this Web component may be ignored by the container. | false |
| false | platform | active | true |
| Servlet:SPEC:173.5 | 15 | 4.2 | JAX-WS and JAXRPC enabled Web component inherits the traditional Web component
mechanisms for defining the following information:
| true |
| false | platform | active | true |
| Servlet:SPEC:173.5.1 | 15 | 4.2 | mapping of the component to the Web container's URL namespace using the servlet mapping technique | true |
| false | platform | active | true |
| Servlet:SPEC:173.5.2 | 15 | 4.2 | authorization constraints on Web components using security constraints | true |
| false | platform | active | true |
| Servlet:SPEC:173.5.3 | 15 | 4.2 | the ability to use servlet filters to provide low-level byte stream support for manipulating JAX-WS and/or JAX-RPC messages using the filter mapping technique | true |
| false | platform | active | true |
| Servlet:SPEC:173.5.4 | 15 | 4.2 | the timeout characteristics of any HTTP sessions that are associated with the component | true |
| false | platform | active | true |
| Servlet:SPEC:173.5.5 | 15 | 4.2 | links to Jakarta EE objects stored in the JNDI namespace | true |
| false | platform | active | true |
| Servlet:SPEC:195 | 15 | 5 | Annotations must be supported on the following container managed classes
that implement the following interfaces and are declared in the web application deployment descriptor
or using the annotations defined in Section8.1, ?Annotations
and pluggability? on page8-65 or added programmatically.
| true |
| false | platform | active | true |
| Servlet:SPEC:195.1 | 15 | 5 | jakarta.servlet.Servlet | true |
| false | platform | active | true |
| Servlet:SPEC:195.2 | 15 | 5 | jakarta.servlet.Filter | true |
| false | platform | active | true |
| Servlet:SPEC:195.3 | 15 | 5 | jakarta.servlet.ServletContextListener | true |
| false | platform | active | true |
| Servlet:SPEC:195.4 | 15 | 5 | jakarta.servlet.ServletContextAttributeListener | true |
| false | platform | active | true |
| Servlet:SPEC:195.5 | 15 | 5 | jakarta.servlet.ServletRequestListener | true |
| false | platform | active | true |
| Servlet:SPEC:195.6 | 15 | 5 | jakarta.servlet.ServletRequestAttributeListener | true |
| false | platform | active | true |
| Servlet:SPEC:195.7 | 15 | 5 | jakarta.servlet.http.HttpSessionListener | true |
| false | platform | active | true |
| Servlet:SPEC:195.8 | 15 | 5 | jakarta.servlet.http.HttpSessionAttributeListener | true |
| false | platform | active | true |
| Servlet:SPEC:195.10 | 15 | 5 | jakarta.servlet.http.HttpSessionIdListener | true |
| false | platform | active | true |
| Servlet:SPEC:195.9 | 15 | 5 | jakarta.servlet.AsyncListener | true |
| false | platform | active | true |
| Servlet:SPEC:196 | 15 | 5 | References must be injected prior to any lifecycle methods being called and
the component instance being made available the the application.
| true |
| false | platform | active | true |
| Servlet:SPEC:197 | 15 | 5 | In a web application, classes using resource injection will have their annotations processed only
if they are located in the WEB-INF/classes directory, or if they are packaged in a jar file located in WEB-INF/lib.
| true |
| false | platform | active | true |
| Servlet:SPEC:198 | 15 | 5 | The web application deployment descriptor contains a metadata-complete attribute on the web-app element.
The metadata-complete attribute defines whether the web descriptor is complete,
or whether other sources of metadata used by the deployment process should be considered.
Metadata may come from the web.xml file, web-fragment.xml files,
annotations on class files in WEB-INF/classes, and
annotations on classes in jar files in the WEB-INF/lib directory.
If metadata-complete is set to "true", the deployment tool only examines the web.xml file and
must ignore annotations such as @WebServlet, @WebFilter, and @WebListener
present in the class files of the application, and must also ignore any web-fragment.xml
descriptor packaged in a jar file in WEB-INF/lib.
If the metadata-complete attribute is not specified or is set to "false",
the deployment tool must examine the class files and web-fragment.xml files for metadata,
as previously specified.
| true |
| false | platform | active | true |
| Servlet:SPEC:289 | 15 | 5 | The web-fragment.xml also contains the metadata-complete attribute on the web-
fragment element. The attribute defines whether the web-fragment.xml descriptor
is complete for the given fragment, or whether it should scan for annotations in the
classes in the associated jar file. If metadata-complete is set to "true" the
deployment tool only examines the web-fragment.xml and must ignore annotations
such as @WebServlet, @WebFilter and @WebListener present in the class files of the
fragment. If metadata-complete is not specified or is set to "false" the deployment
tool must examine the class files for metadata.
| true |
| false | platform | active | true |
| Servlet:SPEC:199 | 15 | 5 | Following are the annotations that are required by a Jakarta EE technology compliant web container. | true |
| false | platform | active | true |
| Servlet:SPEC:199.1 | 15 | 5.4 | The @Resource annotation is used to declare a reference to a resource such as
a data source, Java Messaging Service (JMS) destination, or environment entry.
This annotation is equivalent to declaring a resource-ref, message-destinationref
or env-ref, or resource-env-ref element in the deployment descriptor.
@Resource annotation is specified on a class, method or field.
The container is responsible injecting references to resources declared by
the @Resource annotation and mapping it to the proper JNDI resources.
| true |
| false | platform | active | true |
| Servlet:SPEC:199.2 | 15 | 5.11 | @Resources annotation acts as a container for multiple @Resource annotations
because the Java MetaData specification does not allow for multiple annotations
with the same name on the same annotation target.
| true |
| false | platform | active | true |
| Servlet:SPEC:199.3 | 15 | 5.3 | InjectionComplete annotation is declared on a method which will be called after the resources injections have been completed and before any lifecycle methods on a component are called. This allows application code to do post create processing if necessary. | true |
| false | platform | removed | true |
| Servlet:SPEC:199.4 | 15 | 5.2 | Jakarta Enterprise Beans 4.0 components may be referenced from a web component using the @EJB annotation.
The @EJB annotation provides the equivalent functionality of declaring the ejb-ref
or ejb-local-ref elements in the deployment descriptor.
Fields that have a corresponding @EJB annotation are injected with the a reference to the corresponding Jakarta Enterprise Beans component.
| true |
| false | platform | active | true |
| Servlet:SPEC:199.5 | 15 | 5.13 | The @WebServiceRef annotation provides a reference to a web service in a web component
in same way as a resource-ref element would in the deployment descriptor.
| true |
| false | platform | active | true |
| Servlet:SPEC:199.6 | 15 | 5.1 | @DeclareRoles: This annotation is used to define the security roles that comprise the security model
of the application. This annotation is specified on a class, and if it is used to define
roles that could be tested (i.e., by calling isUserInRole) from within the methods of
the annotated class. Roles that are implicitly declared as a result of their use in a
@RolesAllowed need not be explicitly declared using the @DeclareRoles annotaion.
The @DeclareRoles annotation may only be defined in classes implementing the
jakarta.servlet.Servlet interface or a subclass thereof.
| true |
| false | platform | active | true |
| Servlet:SPEC:199.7 | 15 | 5.12 | The @RunAs annotation is equivalent to the run-as element in the deployment descriptor.
The @RunAs annotation may only be defined in classes implementing the jakarta.servlet.Servlet interface
or a subclass thereof.
| true |
| false | platform | active | true |
| Servlet:SPEC:199.8 | 15 | 5.3 | The @EJBs annotation allows more than one @EJB annotations to be declared on a single resource. | true |
| false | platform | active | true |
| Servlet:SPEC:199.9 | 15 | 5.5 | This annotation(@PersistenceContext) specifies the container managed entity manager
for referenced persistence units.
| true |
| false | platform | active | true |
| Servlet:SPEC:199.10 | 15 | 5.6 | The PersistenceContexts annotation allows more than one @PersistenceContext
to be declared on a resource.
| true |
| false | platform | active | true |
| Servlet:SPEC:199.11 | 15 | 5.7 | The @PersistenceUnit annotation provides Jakarta Enterprise Beans components
declared in a servlet a reference to a entity manager factory. The entity manager
factory is bound to a separate persistence.xml configuration file as described in
section 5.10 of the Jakarta Enterprise Beans 4.0 specification.
| true |
| false | platform | active | true |
| Servlet:SPEC:199.12 | 15 | 5.8 | This annotation(@PersistenceUnits) allows for more than one @PersistentUnit annotations to be
declared on a resource.
| true |
| false | platform | active | true |
| Servlet:SPEC:199.13 | 15 | 5.9 | The @PostConstruct annotation is declared on a method that does not take any
arguments, and must not throw any checked exceptions. The return value must be
void. The method MUST be called after the resources injections have been completed
and before any lifecycle methods on the component are called.
| true |
| false | platform | active | true |
| Servlet:SPEC:304 | 15 | 5.9 | TThe @PostConstruct annnotation MUST be supported by all classes that support
dependency injection and called even if the class does not request any resources to be injected.
If the method throws an unchecked exception the class MUST not be put into service
and no method on that instance can be called.
| true |
| false | platform | active | true |
| Servlet:SPEC:199.14 | 15 | 5.10 | The @PreDestroy annotation is declared on a method of a container managed
component. The method is called prior to component being removed by the
container. The method annotated with @PreDestroy must return void and must not throw a
checked exception. The method may be public, protected, package private or private.
The method must not be static however it may be final.
| true |
| false | platform | active | true |
| Servlet:SPEC:204 | A | 7.1 | sessions of a context must be resumable by requests into
that context regardless of whether their associated context was being
accessed directly or as the target of a request dispatch at the time
the sessions were created.
| true |
| false | technology | active | true |
| Servlet:SPEC:205 | A | 8.1 | (The target servlet of the include method) cannot set
headers or call any method that affects the headers of the response,
with the exception of the HttpServletRequest.getSession() and
HttpServletRequest.getSession(boolean) methods.
Any attempt to set the headers must be ignored,
and any call to HttpServletRequest.getSession() or
HttpServletRequest.getSession(boolean) that would require adding a
Cookie response header must throw an IllegalStateException
if the response has been committed.
| true |
| false | technology | active | true |
| Servlet:SPEC:206 | A | 8.2 | clarify a way to map a filter to all servlet dispatches
... uses the special servlet name '*'.
| true |
| false | technology | active | true |
| Servlet:SPEC:207 | A | 8.3 | (Servlet 2.5) Previous versions of the servlet schema allows only a single url-pattern or servlet name per servlet mapping. For servlets mapped to multiple URLs this results in needless repetition of whole mapping clauses. The deployment descriptor servlet-mappingType was updated to...
| true |
| false | technology | active | true |
| Servlet:SPEC:208 | A | 8.4 | (Servlet 2.5)Previous versions of the servlet schema allows only a single url-pattern in a filter mapping. For filters mapped to multiple URLs this results in needless repetition of whole mapping clauses. The deployment descriptor schema the filter-mappingType was updated to... This change allows multiple patterns and servlet names to be defined in a single mapping | true |
| false | technology | active | true |
| Servlet:SPEC:209 | A | 8.5 | The http-method elements now need to be a token
as described in HTTP 1.1 specification section 2.2.
| true |
| false | technology | active | true |
| Servlet:SPEC:210 | A | 8.8 | If the location of the error handler is a servlet or a JSP page: [...]
The response setStatus method is disabled and ignored if called.
| true |
| false | technology | active | true |
| Servlet:SPEC:211 | A | 8.9 | The API clarification better describes what happens
when a client did not specify a session id.
The API documentation in Section SRV.16.1.3, HttpServletRequest
was updated to specify when false is returned:
Returns false if the client did not specify any session ID.
| true |
| false | technology | active | true |
| Servlet:SPEC:212 | A | 8.10 | Section SRV.5.5, Closure of Response Object was updated
to the following: "The amount of content specified in the
setContentLength method of the response has been greater than zero
and has been written to the response".
the response's content length is set to 0 via
response.setHeader("Content-Length", "0")
and any subsequently setHeader() calls are ignored.
| true |
| false | technology | active | true |
| Servlet:SPEC:213 | A | 8.11 | The API in Section SRV.15.2.16, ServletRequest
was updated to described the behavior if the method is called
after the getReader() was called. If the getReader() is called
there will be no effect.
| true |
| false | technology | active | true |