NonStop Servlets for JavaServer Pages (5.0) System Administrator's Guide

Migrating to NSJSP 5.0
NonStop Servlets for JavaServer Pages (NSJSP) System Administrator’s Guide—525644-002
7-7
Changes from Servlet 2.3 to Servlet 2.4
Changes from Servlet 2.3 to Servlet 2.4
The differences between the Java Servlet 2.4 API specification and Java Servlet 2.3 is
as follows:
•
Java Servlets 2.4 requires HTTP/1.1 and at least the J2SE (Java 2 Platform,
Standard Edition) 1.3 version.
In addition, the HttpServletResponse interface has a new variable called
SC_FOUND for HTTP/1.1 Status code 302. This variable is similar to the variable
SC_MOVED_TEMPORARILY (which has the same 302 status code value), but
represents a tie-in to the HTTP/1.0 specification. All applications should use the
SC_FOUND variable instead of SC_MOVED_TEMPORARILY.
•
An Optional "X-Powered-By" header added to the HttpServletResponse class.
•
A security model is applied to both servlets and filters.
•
FORM authentication failures set status code in the response to 200 (instead of
401).
FORM-based authentication failures result in a Response Status code of 200
(instead of 401) because no appropriate error code exists in the HTTP/1.1
specification to handle such a case.
•
A consistent view of Request and Response wrapper objects in servlet and filters.
•
An application cannot override J2SE platform classes such as those in the java.*
and javax.* namespaces (those platform classes to which J2SE does not allow
modification).
•
Clarification of processing order at web application deployment.
For web applications deployed into the NSJSP Container before the web
application begins processing requests, the setup steps performed internally are:
1. Create an instance of each event listener as configured using the
<listener> element in the deployment descriptor web.xml.
2. For the instantiated listeners call the contextInitialized() method in all
the listeners that implement the ServletContextListener interface.
3. Create an instance of each filter as configured using the <filter> element in
the deployment descriptor web.xml.
4. Finally, create an instance of each servlet as configured using the <servlet>
element in the deployment descriptor web.xml and call the init() method
in all the instantiated servlets. The order in which the servlets are loaded is
governed by the <load-on-startup> sub-element within the <servlet>
elements in the deployment descriptor web.xml.
•
Filters are now used with RequestDispatcher include() and forward() calls.