Some reader favorites:
EJB fundamentals and session beans
Create a scrollable virtual desktop in Swing
Best Java resources?
Where do you go for your continuing education in Java -- what books do you reach for, what feeds do you read, what sites and
bloggers consistently teach and inspire you? Ted Neward has put out a call for the best Java resources, from sites to scripts.
Make your list right here.
| The Four Requirements of Next Generation Web Performance Management |
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?
ServletContextBefore 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 log() methods.
Removed redundancy
The 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, getRealPath() in 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.
Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq
Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq
