Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
This is the first time the Servlet API has had an official specification, and it's the first new release of the Servlet API since announcements of version 2.0 were stuffed in our stockings back in December 1997. This article describes what has changed from version 2.0, explains why the changes were made, and demonstrates how to write servlets using 2.1. To keep the article to a reasonable length, I'm going to assume you're familiar with the classes and methods of Servlet API 2.0. If that's not the case, you can peruse the Resources section for links to sites that will help get you up to speed.
Comparing Servlet API 2.1 to 2.0, how does the new version differ from the previous one?
Before we begin our examination of these differences, let me point out that version 2.1 has been released as a specification
only. No Web server yet supports 2.1. Even the reference
servletrunner implementation is still some weeks away, and commercial Web server support may be even further away release-wise. But on
the bright side,
servletrunner has been entirely rewritten and, when released, should be far more robust than its previous versions.
One of the nicest features of Java is its consistency of naming conventions and design. The Servlet API 2.1 includes a number of small "housecleaning" API changes designed to maintain that consistency -- both internally and with other Java APIs. The following is a rundown of these small changes:
More consistent logging
To begin with, the method
ServletException.log(Exception e, String msg), used to log servlet events, has been deprecated and replaced with
log(String message, Throwable t). This one deprecation fixes two problems. First, it moves the optional
Exception parameter to the end of the argument list, as is the custom in Java. Second, it allows the
log() method to take a
Throwable object, a more general type of exception. This should make the API more predictable and robust.
In addition, the method
log(String message, Throwable t) has been added to the
GenericServlet class. This lets you call
log() directly without first having to get a handle to a
ServletContext. Previously, in 2.0,
GenericServlet only supported the one-argument
log(String msg) method. Now it conveniently supports both
ServletRequest.getRealPath(String path) method, used to determine the actual filesystem location for a given URL path, has been deprecated in favor of a method by
the same name in
ServletContext. API 2.0 included both methods and defined them to perform the same task. Redundancy, though good when it comes to kidneys,
isn't good in an API. Accordingly,
ServletRequest has been removed. Why wasn't the method in
ServletContext deprecated instead? Because path mapping rules depend on a servlet's context, not on any individual client request.