Slava Kozlov wrote:
> Ok, here's a question: I haven't read the 2.2 spec (nor hints about what may
> follow) that thoroughly, but what types of precautions should we (app writers)
> make now in order to (1) prevent our current code from simply breaking and (2)
> to preemptively design for future enhancements?
>
The gap in the servlet API itself between 2.1 and 2.2 is much less likely to break
existing code than the changes from 2.0 to 2.1. This is primarily because nearly
all of the changes are additional functions. The new deprecations are very few,
and the old functionality is still available or easily replaceable.
Where you might need to pay attention is in areas where the 2.1 spec was either
silent or not complete enough to ensure portable implementations. Some of these
areas were identified in Appendix B of the JSP 1.0 spec, as "clarifications" to the
2.1 servlet spec. The following are the highlights of things I've been looking at
in my servlets (many of these were already enforced by 2.1 engines, but are now
mandated in 2.2), in preparation for moving to the new spec:
* ServletContext mapped to a "context path" prefix
(which is available via getContextPath() in 2.2),
but you can define a context that is the "default"
context for a virtual host so that it processes all
requests to that virtual host.
* "Relative" URLs for several calls are interpreted as
relative to the context path, not relative to the
document root of the web server.
* ServletContexts cannot cross virtual host boundaries.
* Sessions cannot cross ServletContext boundaries
(and are therefore local to a web application).
* Rules for mapping servlets via URI prefixes and/or
filename "extensions" are defined, and required to
be supported.
* Arguments to a RequestDispatcher must be the
original request and response objects (which precludes
using a RequestDispatcher to simulate "servlet
chaining").
The 2.2 spec also tightens the rules on servlet engines that provide support for
distributing servlets (and servlet contexts) across multiple VMs (on the same or
different machines). When you include the <distributable> marker in your 2.2
deployment descriptor, you are committing restrictions like only storing
Serializable objects in user sessions. If you do not mark your app as
distributable, the servlet engine (now called a servlet container) is supposed to
ensure that all requests for a particular session are always routed to the same VM.
Of course, there's lots of new things in 2.2 as well. The one I am looking forward
to the most is the declarative security -- now I can delegate login authentication
and management of security roles to the servlet container, and only worry about the
exceptional cases where I might want to add some additional functionality to a page
presented to a manager, versus that same page presented to a regular user.
>
> Wow, we're still on subject! :-)
>
What? An on topic post on SERVLET-INTEREST? Go figure ... :-)
>
> -s
>
Craig McClanahan
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
