Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

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

Servlet 2.4: What's in store

A full update on the latest servlet spec

By Jason Hunter, JavaWorld.com, 03/28/03

Page 2 of 5

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 <locale-encoding-mapping-list> element in the web.xml deployment descriptor to let the deployer assign locale-to-charset mappings outside servlet code. It looks like this:

<locale-encoding-mapping-list>
  <locale-encoding-mapping>
    <locale>ja</locale>
    <encoding>Shift_JIS</encoding>
  </locale-encoding-mapping>
  <locale-encoding-mapping>
    <locale>zh_TW</locale>
    <encoding>Big5</encoding>
  </locale-encoding-mapping>
</locale-encoding-mapping-list>

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 original path, you can call request.getAttribute("javax.servlet.forward.request_uri"). One special caveat: if forward() happens through a getNamedDispatcher() call, these attributes aren't set because, in that case, the original path elements aren't changed.

This set of attributes may remind you of these request attributes added with Servlet 2.2: