Programming Tutorials Browser Tutorials Articles Struts Tutorials Hibernate Tutorials

  Tutorial: Servlet 2.4: What's in store

Servlet 2.4: What's in store

Tutorial Details:

Servlet 2.4: What's in store
Servlet 2.4: What's in store
By: By Jason Hunter
A full update on the latest servlet spec
n March 7, 2003, Sun Microsystems (working with the JSR (Java Specification Request) 154 expert group) published the "Proposed Final Draft 2" of the Servlet 2.4 specification (see Resources for a link to the formal specification). As it's still in the Proposed Final Draft stage, the specification is not quite finished, and technical details may change. A Proposed Final Draft 3 is even a possibility. However, changes should not prove significant before the specification's final release, and, in fact, server vendors have already begun to implement the new features. That makes now a good time to start learning about what's coming in Servlet 2.4 and check out its integration with J2EE (Java 2 Platform, Enterprise Edition) 1.4.
In this article, I describe what changed between 2.3 and 2.4. I also explain the decision-making process behind the changes and tell you about a few things that didn't make it. To keep the article focused, I assume you're familiar with the classes and methods of previous Servlet API versions. If that's not the case, you can peruse Resources for links to sites (and my book!) that will help get you up to speed.
Servlet 2.4 lacks some of the fireworks of past releases. Servlet 2.2 introduced the notion of self-contained Web applications. Servlet 2.3 added the power of filters and filter chains. Servlet 2.4, while adding several interesting features, has no superstars and spends more time polishing and clarifying the features that came before?a tying up of loose ends. This work's effect is that servers faithfully implementing 2.4 will be more interoperable than any past servers. But don't let me imply there's nothing new in Servlet 2.4! Here's a list of what's new:
Servlets now require HTTP/1.1 and J2SE (Java 2 Platform, Standard Edition) 1.3, and can work with J2EE 1.4
ServletRequest has new methods to observe the client connection
New support for internationalization and charset choice
RequestDispatcher has new features and clarifications
New ServletRequest listener classes and methods
A deprecated SingleThreadModel
HttpSession details and interaction with logins has been clarified
Classloading and welcome-file behavior has been clarified
The web.xml file now uses XML Schema and has added a slew of new elements
Before we begin looking at these changes, let me point out that most servers don't yet have fully compliant Servlet 2.4 implementations. If you want to test those features, your best bet is to download the official reference implementation server, Apache Tomcat 5.0. It's open source, and you can download the server for free. Tomcat 5.0 will be the first Tomcat version to support Servlet 2.4, but, of course, its latest release is still an alpha. (See Resources for more information on Tomcat.)
Upgraded support for HTTP, J2SE, and J2EE
Servlet 2.4 depends on HTTP/1.1 and J2SE 1.3. Previously, servlets relied upon HTTP/1.0 and J2SE 1.2. Having 2.4 upgrade these minimum-level requirements means servlet authors can reliably depend on the new features of HTTP/1.1 and J2SE 1.3. At the same time, these requirements complicate the task of the servlet container developer because HTTP/1.1 has more special cases and complexities than HTTP/1.0. Some servers already support HTTP/1.1, but those that don't will have to spend some time upgrading. Note that, unlike what some people think, having J2SE 1.3 as a minimum requirement does not mean that if you implement Servlet 2.4 on J2SE 1.2, you've succeeded with a good hack. That breaks the contract with the servlet author, a contract that says an author may rely on J2SE 1.3 features when he writes against Servlet 2.4.
As another change, Servlet 2.4 will be part of the upcoming J2EE 1.4 (in fact, the two specs will be released concurrently, probably around JavaOne 2003). Of course, it's important to note that servlets can run standalone; you don't have to buy a full J2EE container to run servlets. Apache Tomcat, for example, doesn't implement all of J2EE. But when you run servlets as part of J2EE 1.4, you can take advantage of extra features and extra deployment descriptor elements exposing JNDI (Java Naming and Directory Interface) resources, EJB (Enterprise JavaBeans), message queues, and JAX-RPC (Java API for XML-based Remote Procedure Call) services. I'll talk about some of those elements later.
The upgrade to HTTP/1.1 caused one code change. Servlets have a new static constant HttpServletResponse.SC_FOUND to represent status code 302. Found is the HTTP/1.1 name for what HTTP/1.0 called Moved temporarily . HttpServletResponse.SC_MOVED_TEMPORARILY still exists and represents 302, but SC_FOUND is now preferred. SC_MOVED_TEMPORARILY can be considered deprecated, but deprecating variables, even public constants is technically impossible in Java.
New ServletRequest methods
The ServletRequest interface (and the ServletRequestWrapper class) adds four new methods in Servlet 2.4:
getRemotePort() : Returns the IP source port of the client or last proxy that sent the request
getLocalName() : Returns the host name of the IP interface on which the request was received
getLocalAddr() : Returns the IP address of the interface on which the request was received
getLocalPort() : Returns the IP port number of the interface on which the request was received
These methods provide a mechanism to query the low-level IP connection details and understand how the connection routed. The getRemotePort() method, combined with the preexisting getRemoteAddr() and getRemoteHost() methods, exposes the client side of the IP connections. The new getLocalPort() , getLocalAddr() , and getLocalName methods expose the server side of the IP connections. The preexisting getServerName() and getServerPort() methods have been newly defined to expose the HTTP-layer details by simply returning the "host:port" extracted from the HTTP Host header. On a virtual hosted or load-balanced system, these methods provide a way to learn what clients, proxies, or load-balance devices connect, where they physically connect, and where they virtually connect.
Internationalization
Also in Servlet 2.4, the ServletResponse interface (and the ServletResponseWrapper ) adds two new methods:
setCharacterEncoding(String encoding) : Sets the response's character encoding. This method provides an alternative to passing a charset parameter to setContentType(String) or passing a Locale to setLocale(Locale) . This method has no effect if called after getWriter() has been called or if the response has committed. For a list of acceptable Internet charsets, see Resources .
getContentType() : Returns the response's content type. This may include a charset parameter set by either setContentType() , setLocale() , or setCharacterEncoding() . If no type has been specified, the method returns null.
The setCharacterEncoding() method pairs with the preexisting getCharacterEncoding() method to provide an easy way to manipulate and view the response's character encoding (charset). You can now avoid setting the charset via the awkward setContentType("text/html; charset=UTF-8") call.
The new getContentType() method pairs with the preexisting setContentType() method to expose the content type you've assigned. Formerly, this wouldn't have been too interesting, but now the type might be dynamically set with a combination of setContentType() , setLocale() , and setCharacterEncoding() calls, and this method provides a way to view the generated type string.
So which is better, setLocale() or setCharacterEncoding() ? It depends. The former lets you specify a locale like ja for Japanese and lets the container handle the work of determining an appropriate charset. That's convenient, but, of course, many charsets might work for a given locale, and the developer has no choice in the matter. The latter method provides a new, easy way to choose a specific charset, letting you override the container's choice of Shift_JIS with EUC-JP , for example.
However, the story doesn't end there. Servlet 2.4 also introduces a new element in the web.xml deployment descriptor to let the deployer assign locale-to-charset mappings outside servlet code. It looks like this:


ja
Shift_JIS


zh_TW
Big5


Now within this Web application, any response assigned to the ja locale uses the Shift_JIS charset, and any assigned to the zh_TW Chinese/Taiwan locale uses the Big5 charset. These values could later be changed to UTF-8 when it grows more popular among clients. Any locales not mentioned in the list will use the container-specific defaults as before.
RequestDispatcher changes
Servlet 2.4 adds five new request attributes to provide extra information during a RequestDispatcher forward() call. In case you've forgotten, when you forward() to a servlet, the servlet container changes the target servlet's path environment as if it were the first servlet being invoked. The methods getRequestURI() , getContextPath() , getServletPath() , getPathInfo() , and getQueryString() all return information based on the URI (Uniform Resource Identifier) passed to the getRequestDispatcher() method. However, sometimes an advanced forward() target servlet might like to know the true original request URI. For this, Servlet 2.4 adds the following request attributes:
javax.servlet.forward.request_uri
javax.servlet.forward.context_path
javax.servlet.forward.servlet_path
javax.servlet.forward.path_info
javax.servlet.forward.query_string
Inside a forwarded servlet you'll see getRequestURI() return the path to the target servlet as always, but now if you want the origi


 

Read Tutorial at: Click here to view the tutorial

Rate Tutorial:
Servlet 2.4: What's in store

View Tutorial:
Servlet 2.4: What's in store

Related Tutorials:

Understanding JavaServer Pages Model 2 architecture - JavaWorld December 1999
Understanding JavaServer Pages Model 2 architecture - JavaWorld December 1999
 
Building a Java servlet framework using reflection, Part 2 - JavaWorld February 2000
Building a Java servlet framework using reflection, Part 2 - JavaWorld February 2000
 
Create a custom Java 1.2-style ClassLoader - JavaWorld March 2000
Create a custom Java 1.2-style ClassLoader - JavaWorld March 2000
 
Using XML and JSP together - JavaWorld March 2000
Using XML and JSP together - JavaWorld March 2000
 
Secure a Web application, Java-style - JavaWorld April 2000
Secure a Web application, Java-style - JavaWorld April 2000
 
Take control of the servlet environment, Part 1 - JavaWorld November 2000
Take control of the servlet environment, Part 1 - JavaWorld November 2000
 
Take control of the servlet environment, Part 2 - JavaWorld December 2000
Take control of the servlet environment, Part 2 - JavaWorld December 2000
 
Take control of the servlet environment, Part 3 - JavaWorld January 2001
Take control of the servlet environment, Part 3 - JavaWorld January 2001
 
Deliver cellular messages with SMS - JavaWorld March 2001
Deliver cellular messages with SMS - JavaWorld March 2001
 
Manage distributed sessions - JavaWorld April 2001
Manage distributed sessions - JavaWorld April 2001
 
Jtrix: Web services beyond SOAP
Jtrix: Web services beyond SOAP
 
Servlet 2.4: What's in store
Servlet 2.4: What's in store
 
good design pattern
good design pattern
 
Introduction to JSP
Introduction to JSP Introduction to JSP Java Server Pages or JSP for short is Sun's solution for developing dynamic web sites. JSP provide excellent server side scripting support for creating database driven web applications. JSP enable the
 
Servlet Essentials
This document explains the concepts of Java Servlets and provides a step-by-step tutorial for writing HTTP Servlets with complete source code for the example Servlets. The tutorial and the other chapters cover all facets of Servlet programming from a ...
 
ColdCafe ver 1.2
ColdCafe is a macro-processor servlet. This servlet parses html pages and replaces some predefined elements with their values. It is not a new language like JSP, it is just a set of html-preprocessing that keep your hands free for using any web-authoring
 
The J2EE Architecture allows the programmers to divide their work into two major categories Business Logic Presentation
The J2EE Architecture allows the programmers to divide their work into two major categories Business Logic Presentation Logic J2EE Architecture The J2EE Architecture allows the programmers to divide their work into two major categories: Business
 
Building Web Application With Ant and Deploying on Jboss 3.0
Building Web Application With Ant and Deploying on Jboss 3.0 Building Web Application With Ant and Deploying on Jboss 3.0 Previous Tutorial Index Next In this lesson I will show you how to build you web application and install on the Jboss 3.0
 
developing a Session Bean and a Servlet and deploy the web application on JBoss 3.0
developing a Session Bean and a Servlet and deploy the web application on JBoss 3.0 Writing Stateless Session Bean and Calling through Servlet Previous Tutorial Index Next In this lesson I will show you how to develop a Stateless Session Bean and
 
Understanding Struts Controller
Understanding Struts Controller Understanding Struts Controller In this section I will describe you the Controller part of the Struts Framework. I will show you how to configure the struts-config.xml file to map the request to some destination
 
Site navigation
 

 

Send your comments, Suggestions or Queries regarding this site at roseindia_net@yahoo.com.

Copyright © 2006. All rights reserved.