Servlets Tutorials and Guide

Deployment Descriptor in Different Servlet Versions

November 26, 2013 by Krishna Srinivasan Leave a Comment

Servlet specifications evolved over the period of time. There is lot of improvements has been added to the web deployment descriptor as part of the new versions. It is important for the Java developers to understand the new elements in the web.xml and utilize the added features.

In this tutorial I will summarize the sample snippet from the list of web.xml file used in the previous versions of servlet. Primarily I have listed the XML schema that have updated on different versions of servlet. This will help you to understand the evolution of servlet configuration file and the latest improvements. If you have any questions, please write it in the comments section.

1. Servlet 2.3

This version uses the Document Type Definition (DTD) validation for the web.xml validation. This is the traditional way of validation before the XML schema validation. After the XSD’s introduction, it is not recommended to use DTD.

[code lang=”xml”]
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd" >

<web-app>
<display-name>Servlet 2.3 Sample Application</display-name>
</web-app>
[/code]

2. Servlet 2.4

First time in Servlet 2.4, XSD is used for the validation of XML contect. This version of the deployment descriptor is used for long time and become most popular.

[code lang=”xml”]
<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">
<web-app>
<display-name>Servlet 2.4 Sample Application</display-name>
</web-app>
[/code]

3. Servlet 2.5

In the version XML namspace changed from J2EE to JavaEE as http://java.sun.com/xml/ns/javaee.

[code lang=”xml”]
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" version="2.5">
<web-app>
<display-name>Servlet 2.5 Sample Application</display-name>
</web-app>
[/code]

4. Servlet 3.0

This is the latest major servlet release with lot of advanced features. Not most of the projects are adopted this version. Still most of the projects are using Servlet 2.5 version.

[code lang=”xml”]
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
<web-app>
<display-name>Servlet 3.0 Sample Application</display-name>
</web-app>
[/code]

Asynchronous Servlet – A new feature in Servlet 3.0 and Java EE 6

October 6, 2013 by Mohamed Sanaulla Leave a Comment

When Java EE 6 was announced with a new servlet specification i.e Servlet 3.0 – Asynchronous servlet was a very important feature added to the new specification. Suppose your servlet does a long running task like making a JDBC call or invoking a web service, such operations generally take up a lot of CPU time leading to keeping a Thread engaged for the same. This Thread allocated for a request is blocked waiting for the result of the long operation and hence can lead to resource starvation when many such requests are engaged by the server.

This and other problems which come with servlet handling long running tasks can be mitigated by using Asynchronous servlet. An asynchronous servlet releases the Thread back to the server pool and lets the long running task to proceed in the back ground. This long running task takes with it a context object which can be used to intimate the server of the availability of the result and this result can then be relayed back to the client from the server. Such process of server pushing the data to the client is called “Server Push” or “Comet” which is complimentary to “Ajax” which is a client side pull.

In this post I will show you how to create a Asynchronous Servlet and then make an Ajax call from the JSP to this servlet. And the JSP will display the output from the servlet. But before I go into that let me list out the classes which are used for creating Asynchronous servlet so that we have an idea of these classes before looking into the code.

Classes used for creating Asynchronous Servlet

AsyncContext: From the Javadoc:

AsyncListener: From the Javadoc:

The AsyncContext object holds the state of the request and response. Either the request and response object is taken from the current context or one can provide their request and response objects while initiating the asynchronous operation.

Creating the Long running task

Lets now create a long running task which has to be invoked from our servlet. This long running task implements Runnable so that it can be handed over to a Thread pool to be executed. Also this task takes in a AsyncContext object which is provided by the servlet. Lets look at the code for our long running task:

[code lang=”java” highlight=”25,28,32,58″]
import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.AsyncContext;
/**
* Long running task which is to be invoked by our servlet.
*/
public class DemoAsyncService implements Runnable {

/**
* The AsyncContext object for getting the request and response
* objects. Provided by the servlet.
*/
private AsyncContext aContext;

public DemoAsyncService(AsyncContext aContext) {
this.aContext = aContext;
}

@Override
public void run() {
PrintWriter out = null;

try {
//Retrieve the type parameter from the request. This is passed in the URL.
String typeParam = aContext.getRequest().getParameter("type");

//Retrieve the counter paramter from the request. This is passed in the URL.
String counter = aContext.getRequest().getParameter("counter");

System.out.println("Starting the long running task: Type="+typeParam+", Counter: "+counter);

out = aContext.getResponse().getWriter();

//Sleeping the thread so as to mimic long running task.
Thread.sleep(5000);

/**
* Doing some operation based on the type parameter.
*/
switch (typeParam) {
case "1":
out.println("This process invoked for "+ counter +" times.");
break;
case "2":
out.println("Some other process invoked for "+ counter +" times.");
break;
default:
out.println("Ok… nothing asked of.");
break;
}

System.out.println("Done processing the long running task: Type="+typeParam+", Counter: "+counter);

/**
* Intimating the Web server that the asynchronous task is complete and the
* response to be sent to the client.
*/
aContext.complete();

} catch (IOException |InterruptedException ex) {
ex.printStackTrace();
}
finally{
out.close();
}
}
}
[/code]

The important parts in the above code have been highlighted- namely line 25, line 28, line 32, line 58. In Line 25 and Line 28 we make use of the AsyncContext object to retrieve data from the request object i.e HttpServletRequest object. In Line 32 we make use of the same AsyncContext object to obtain the output stream from the response object i.e HttpServletResponse object. The Line 58 is a bit interesting as this is the main part of the asynchronous processing. This line says to the web server that the asynchronous processing is completed and the response can be sent back to the client. The other way to let this happen is by invoking: aContext.dispatch() method.

Creating the Asynchronous servlet

Now that we have a long running task to be invoked, its time to write our Asynchronous servlet. Asynchronous servlet is not much different from the usual servlet. To let the application server know that the servlet is asynchronous we have to set the asyncSupported attribute in the @WebServlet annotation to true. Or if you are using a Deployment descriptor i.e web.xml file to register your servlet then by adding tag within the servlet registration xml code we can let the server know that the given servlet is asynchronous.

Once we have done the identification for the asynchronous servlet, we need to get the AsyncContext object and then fire the long running task from within the servlet. When we fire the asynchronous operation we can register a callback which will be invoked as and when our operation is completed or timed out or runs into some error. Lets look at the code for the servlet:

[code lang=”java” highlight=”6,25,29,57″]
/**
* Our Asynchronous servlet with URL pattern = /asyncHello
*/
@WebServlet(name = "DemoAsyncServlet",
urlPatterns = {"/asyncHello"},
asyncSupported = true)
public class DemoAsyncServlet extends HttpServlet {

/**
* Processes requests for both HTTP
* <code>GET</code> and
* <code>POST</code> methods.
*
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
protected void processRequest(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {

System.out.println("Async Servlet with thread: " + Thread.currentThread().toString());

//Starting the asynchronous handling and obtaining the AsyncContext object.
AsyncContext ac = request.startAsync();

//Registering a listener with the AsyncContext object to listen to events
//from the AsyncContext object.
ac.addListener(new AsyncListener() {
@Override
public void onComplete(AsyncEvent event) throws IOException {
System.out.println("Async complete");
}

@Override
public void onTimeout(AsyncEvent event) throws IOException {
System.out.println("Timed out…");
}

@Override
public void onError(AsyncEvent event) throws IOException {
System.out.println("Error…");
}

@Override
public void onStartAsync(AsyncEvent event) throws IOException {
System.out.println("Starting async…");
}
});

/**
* Scheduling our Long running process using an inbuilt ThreadPool. Note
* that we are passing the AsyncContext object to our long running process:
* DemoAsyncService.
*/
ScheduledThreadPoolExecutor executer = new ScheduledThreadPoolExecutor(10);
executer.execute(new DemoAsyncService(ac));
System.out.println("Servlet completed request handling");

}

/**
* Handles the HTTP
* <code>GET</code> method.
*
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
processRequest(request, response);
}

}
[/code]

In the above code the interesting pieces of code are: Line 6, Line 25, Line 29, Line 57. In Line 6 we are declaring the servlet to be an asynchronous one. In Line 25 and Line 29 we are setting up the asynchronous context and registering an listener respectively. And in Line 57 we are launching our long running process from the servlet.

Invoking the Asynchronous servlet from the JSP

Lets go ahead and make an Ajax request to our asynchronous servlet. In our JSP we will have 2 buttons which on clicking them will updated the UI with some data from the server. Lets look at the JSP code for asyncSample.jsp:

[code language=”xml”]
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>JSP Page</title>
<script src="asyncSample.js"></script>
</head>
<body>
<h1>Hello World!</h1>
<input type="button" id="ajaxBt1" value="Update data" /> <br/>
<div id="req1Response"></div>
<input type="button" id="ajaxBt2" value="Update some other data" />
<div id="req2Response"></div>
</body>
</html>
[/code]

And we do the event handling binding and setting up the Ajax calls in a different Javascript file: asyncSample.js:

[code lang=”javascript”]
window.onload = setupEventHandlers;

//Counters to record the number of times the buttons were clicked.
var counter1;
var counter2;

//setting up the event handlers for the button
function setupEventHandlers() {
counter1 = 1;
counter2 = 1;
var ajaxBtn1 = document.getElementById("ajaxBt1");
var ajaxBtn2 = document.getElementById("ajaxBt2");
ajaxBtn1.onclick = handleAjaxBtn1;
ajaxBtn2.onclick = handleAjaxBtn2;

}

//Event handlers for the buttons

The above code does the following:
1. Fetches the buttons declared in the JSP using their IDs.
2. Registers the click handlers for these buttons.
3. The click handlers then make Ajax requests to our servlet.
4. The ajax callbacks then update the UI with the output sent from the server.

Note: I am using Netbeans IDE 7.3.1 and Java EE 7 with Glassfish 4. This code can run on Java EE 6 as well. Once all the above are completed, we can deploy the application to app server and launch it in the browser using the: http://localhost:8080/DemoApplication/asyncSample.jsp URL.

You should see the below on your browser page on opening the URL for the first time:

And once you click on different buttons you would see the UI changing to:
Hope you like the article. It is one of the interesting and significant feature introduced with Servlets 3.0. In the future articles, I would continue writing the various topics on Servlets 3.0 and Java EE 6.0. You can receive the latest updates on our blog by connecting to our social network profiles.

What is load on startup element in web.xml file

February 21, 2013 by Krishna Srinivasan Leave a Comment

specify the order in which we want to initialize various Servlets. Like first initialize Servlet1 then Servlet2 and so on.
This is accomplished by specifying a numeric value for the <load-on-startup> tag. <load-on-startup> tag specifies that the servlet should be loaded
automatically when the web application is started.

The value is a single positive integer, which specifies the loading order. Servlets with lower values are loaded before servlets with
higher values (ie: a servlet with a load-on-startup value of 1 or 5 is loaded before a servlet with a value of 10 or 20). When loaded, the init() method of the servlet is called. Therefore this tag provides a good way to do the following:

start any daemon threads, such as a server listening on a TCP/IP port, or a background maintenance thread perform initialisation of the application, such as parsing a settings file which provides data to other servlets/JSPs If no <load-on-startup> value is specified, the servlet will be loaded when the container decides it needs to be loaded – typically on it’s first access. This is suitable for servlets that don’t need to perform special initialisation.

I hope that clears all the doubts regarding <load-on-startup> in web.xml.

ServletContextListener Example

February 26, 2009 by Krishna Srinivasan Leave a Comment

This tips explains the how to use ServletContextListener. There will be only one ServletContext for each web application. ServletContext will be created while deploying the application. Once the ServletContext is created, it will be used by all the servlets and jsp files in the same application. ServletContext is also called as the application scope variables in the web application scenario.

ServletContextListener has the following two methods:

public void contextInitialized(ServletContextEvent event)
public void contextDestroyed(ServletContextEvent event)

Look into the following example for how to implement the ServletContextListener methods:

ServletContextExample.java

[code lang=”java”]
package example;

import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

public class ServletContextExample implements ServletContextListener{
ServletContext context;
public void contextInitialized(ServletContextEvent contextEvent) {
System.out.println("Context Created");
context = contextEvent.getServletContext();
// set variable to servlet context
context.setAttribute("TEST", "TEST_VALUE");
}
public void contextDestroyed(ServletContextEvent contextEvent) {
context = contextEvent.getServletContext();
System.out.println("Context Destroyed");
}
}
[/code]

web.xml

[code lang=”xml”]
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
<listener>
<listener-class>
example.ServletContextExample
</listener-class>
</listener>
</web-app>
[/code]

In the above example ServletContextExample implements ServletContextListener. It has two methods contextInitialized which is called when the ServletContext is created. Another one is contextDestroyed which is called while context is destroyed, this happens normally when web server is shut down or crash.

load-on-startup element in web.xml

February 17, 2009 by Krishna Srinivasan Leave a Comment

This tips explains the few points on how to use the load-on-startup element on the web.xml file. Whenever is starting, it is possible to tell the container to load a servlet on the startup. You can load any number of servlets on the startup. Normally this is done for any initialization purpose. Look into the following example:

[code lang=”xml”]
<servlet>
<servlet-name>TestServlet</servlet-name>
<servlet-class>TestServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
[/code]

The above example tells the container that the servlet will be loaded at first.The <load-on-startup> sub-element indicates the order in which each servlet should be loaded. Lower positive values are loaded first. If the value is negative or unspecified, then the container can load the servlet at anytime during startup.

New Features in Servlets 2.5

January 6, 2009 by Krishna Srinivasan Leave a Comment

1.Introduction

This article presents new features introduced in the Servlet 2.5. Servlet 2.5 is bundled with Java EE 5.0 edition and it has lot of new features. This version has major changes since it has to support the Java 5.0 version for all the J2EE technologies. One of the notable changes will be supporting Generics and Annotations. Using annotations in Java EE environment has simplified the developement process by eliminzating the much need for XML deployment descriptors.

EJB 3.0 is example for how it is simple compare to its previous versions. In the same way other technologies also have significent updates. One particular technology is Servlet and it is evloving very quickly. This Servlet 2.5 has few changes and the next version Servlet 3.0 has very exciting features like Web Fragments. The minimum requirement for the Servlet 2.5 is JDK 5.0 or above. Lets look into the Servlet 2.5 features in this article.

The following are the list of notable features in servlet 2.5:

Support for Annotations
Deployment descriptor changes
Removed restriction on error handling

2.Annotations in Servlet 2.5

Annotations are a new language feature provided as part of JSR 175 (A Metadata Facility for the Java Programming Language). One of the major change in the Servlet 2.5 is its full support for the Java 5.0 version. The minimum requirement for Servlet 2.5 is the JDK 5.0 installed in your system. Servlet 2.5 introduces annotations programming in the Servlets technology.

The annotations has to be loaded into the containers memory while server start up. This will take up more time since the container has to scan all the files in the classpath including jar files to find all the annotations. There is option to diable annotations by using the metadata-complete attribute in the web.xml file. If you set this value as “true”, then the container will ignore all the annotations in the Servlet files. If you specify as “false” or ignore that, by default it will search for the annotations declaration. Look into the folloing sample code:

[code lang=”xml”]

<web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5" metadata-complete="true">
</web-app> [/code]

By default container will look into folders WEB-INF/classes and WEB-INF/lib for loading the servlets. Optionally container can search on the other location also. We will look into the details of few annotation in the next sections. The following are the few annotations introduced in the Servlet 2.5:

@DeclaresRoles
@EJB
@EJBs
@Resource
@Resources
@PostConstruct
@PreDestroy
@PersistanceContext
@PersistanceUnit

2.1.@EJB

EJB 3.0 components can be injected to a Servlet class by using the @EJB annotation. In the deployment descriptors this can be declared using the ejb-ref and ejb-local-ref elements. @EJB annotation can be used infront of a field to inject any EJB 3.0 reference to that field. Like the following example:

[code lang=”xml”] @EJB private LoginSample loginSample;[/code]

2.2.@EJBs

@EJBs annotation can be used for declraing more than one EJB in single line of declaration. For example:

[code lang=”java”] @EJBs({@EJB(LoginSample),@EJB(ProcessSample)})[/code]

2.3.@Resource

@Resource annotation used for declaring any of the resources like datasource, messaging destination,etc. @Resource annotation can be used for class,method or a field. Look into the following example:

[code lang=”java”] @Resource private javax.sql.DataSource mysqlDs;[/code]

2.4.@Resources

@Resources annotation is used for declaring more than one @Resource in a single line. For example:

[code lang=”java”] @Resources({@Resource(name="mysqlDs" type=javax.sql.DataSource),
@Resource(name="factory" type=javax.jms.ConnectionFactory) })[/code]

2.5.@PostConstruct

The @PostConstruct annotation is declared on a method that does not take any arguments, and must not throw any checked expections. The return value must be void. The method MUST be called after the resources injections have been completed and before any lifecycle methods on the component are called.

[code lang=”java”] @PostConstruct public void postConstruct() { }[/code]

2.6.@PreDestroy

The @PreDestroy annotation is declared on a method of a container managed component. The method is called prior to component being reomvoed by the container.

[code lang=”java”] @PreDestroy public void preDestroy() { }[/code]

3.Error Handling

Servlet 2.5 removed a few restrictions around error handling and session tracking. Now it has removed the restriction that the <error-page> could not call the setStatus() method to alter the error code that triggered them. In session tracking, Servlet 2.5 eased a rule that a servlet called by RequestDispatcher include() couldn’t set response headers.

4.Servlets 2.5 web.xml changes

Servlets 2.5 has added few changes on the web.xml file. It is not major changes, but even though gives more
flexibility on mapping the filters and servlets. The two changes are in the filter-mapping and servlet-mapping elements.

4.1.servlet-mapping

In the previous version you are allowed to use only the single url-pattern inside the servlet-mapping. This has the restriction or drawback if you want to map more than one url for the single servlet. Servlet 2.5 updated this element so that you can add more than one url-pattern for the single servlet mapping. Look into the following example code:

[code lang=”xml”]
<servlet-mapping>
<servlet-name>JavaBeatServlet</servlet-name>
<url-pattern>/servlets/*</url-pattern>
<url-pattern>/servlet/javabeat/*</url-pattern>
<url-pattern>/*</url-pattern>
</servlet-mapping>
[/code]

The above snippet adds three url-pattern inside the single servlet-mapping element. This is more useful when you have the requirement to add three different url’s to be mapped for a single servlet-name element.

4.2.filter-mapping

Like the above changes in the servlet-mapping, filter-mapping has two changes. First one is introducing the wildcard(*) for filter-mapping.

[code lang=”xml”]
<filter-mapping>
<filter-name>Java Filter</filter-name>
<servlet-name>*</servlet-name>
</filter-mapping>
[/code]

In the above example, all the requests will be redirected to the particular filter name. Another change is multiple entry in the
filter-mapping. It is same as the servlet mappintg, we can add multiple entries in the filter-mapping.

[code lang=”xml”]
<filter-mapping>
<filter-name>Game Filter</filter-name>
<url-pattern>/games/*</url-pattern>
<servlet-name>PlayGame</servlet-name>
<servlet-name>StopGame</servlet-name>
</filter-mapping>
[/code]

The above code is example for multiple entries in the filter-mapping.

5.Summary

This article explains what are the new features in Servlet 2.5 version. The main goal of this release is to provide Java 5.0 support and to start using the features like annotations and generics. In the next versions we can see there will be more changes.

Servlets 2.5 Reference

New Features in Servlets 3.0

December 23, 2008 by Krishna Srinivasan Leave a Comment

Introduction

This article covers most of the important features available as part of Servlet 3.0 specification. Note that the Servlet 3.0 specification constantly keeps changing frequently with the reviews coming in and the features and the API’s mentioned in this article is based on the specification that is available in JCP for public review as of December 2008. This article focuses on the new set of annotations introduced that can be used by developers rather than put the data in the configuration file, followed by the enhanced Pluggability and the extension support for adding third-party frameworks. The article is finally concluded by detailing about the asynchronous execution of processing and the usage for the same. JSR 315 talks about the Servlet 3.0 features. For attitional information please read the reference section of this article.

Ease of Development through Annotations

The configuration information about a component in a typical web application is expressed in an external meta file. The information about web components such as Servlets, Servlet Filters are mentioned in the deployment descriptor, which is web.xml. Starting from Servlet 3.0, it is also possible to specify the meta information about a component in the definition of a component itself, through Annotations. It doesn’t mean the deployment descriptor is now gone, deployment descriptor in the form of web.xml is still there. In fact information specified in the deployment descriptor takes precedence over the information specified through Annotations.

The Servlet 3.0 specification also provides an option for instructing the Web Container, whether the container should process the annotations defined on the web components. The name of the element is metadata-complete and it is a child element of web-app element. The metadata-complete element indicates whether the meta-data information available in the deployment descriptor is complete. So, if the value for the metadata-complete element is set to a value of true, then it means that the meta information found in the deployment descriptor is complete and eventually the annotations defined on the web components will be ignored by the Servlet Container. If the value for metadata-complete is set to false, then it means that the information in the deployment descriptor is not complete and web components decorated with annotations, if any, should be scanned and processed by the Web Container.

The following annotations are applicable starting from Servlet 3.0 specification,

@WebServlet
@WebServletContextListener
@ServletFilter
@InitParam

Web Servlet and InitParam Annotation

In this section, we will see the usage of @WebServlet and @InitParam using an example. Look at the following code,

SimpleServlet.java

[code lang=”java”]
package net.javabeat.servlet30.newfeatures;

import javax.servlet.annotation.InitParam;
import javax.servlet.annotation.WebServlet;

@WebServlet(
name = "SimpleServlet",
urlPatterns = {"/simple"},
initParams = {
@InitParam(name = "param1", value = "value1"),
@InitParam(name = "param2", value = "value2")}
)
public class SimpleServlet {

}[/code]

In the example, we have declared a class by name SimpleServlet and this class is not made to extend or implement any of the Servlet/HttpServlet types. Instead, to qualify this class as a Servlet class we have annotated using @WebServlet annotation. Note that the name of the servlet is SimpleServlet as specified through the name attribute. The attribute urlPatterns defines a set of url-patterns that can be used to invoke the Servlet. The Servlet Container after scanning this class will generate the deployment descriptor which may look like the following,

web.xml

[code lang=”java”]
…

<servlet>
<servlet-name>SimpleServlet</servlet-name>
<servlet-class>net.javabeat.servlet30.newfeatures.SimpleServlet</servlet-class>

<init-param>
<param-name>param1</param-name>
<param-value>value1</param-value>
</init-param>

<init-param>
<param-name>param2</param-name>
<param-value>value2</param-value>
</init-param>

</servlet>

<servlet-mapping>
<url-pattern>/simple</url-pattern>
<servlet-name>SimpleServlet</servlet-name>
</servlet-mapping>

…
[/code]

Filter annotation

The @Filter annotation defines a Servlet Filter component for a web application. A filter is typically used to intercept a web request for performing any of the pre-processing operations well before reaching the actual servlet component. Let us see the definition of a filter component using Servlet 3.0 approach,

SimpleFilter.java

[code lang=”java”]
package net.javabeat.servlet30.newfeatures;

import javax.servlet.annotation.InitParam;
import javax.servlet.annotation.ServletFilter;

@ServletFilter(
filterName = "SimpleFilter",
urlPatterns = "/simple",
initParams =
{@InitParam(name = "param1", value = "value1"),
@InitParam(name = "param2", value = "value2")}
)
public class SimpleFilter {

}
[/code]

Again, to support backward compatibility, the annotation information in the above class will be transformed as information in the deployment descriptor by the Servlet Container and the deployment descriptor might look like this,

web.xml

[code lang=”java”]
…

<filter-name>SimpleFilter</filter-name>
<filter-class>net.javabeat.servlet30.newfeatures.SimpleFilter</filter-class>

<init-param>
<param-name>param1</param-name>
<param-value>value1</param-value>
</init-param>

<init-param>
<param-name>param2</param-name>
<param-value>value2</param-value>
</init-param>

</filter>

<filter-mapping>
<filter-name>SimpleFilter</filter-name>
<url-pattern>/simple</url-pattern>
<filter-mapping>

…
[/code]

Servlet Context Listener annotation

The Servlet Context Listener is used to receive events whenever the servlet context is created and destroyed by the Web Container. Let us see an usage of this annotation,

SimpleServletContextListener.java

[code lang=”java”]
package net.javabeat.servlet30.newfeatures;

import javax.servlet.ServletContextEvent;
import javax.servlet.annotation.WebServletContextListener;

@WebServletContextListener()
public class SimpleServletContextListener {

public void contextInitialized(ServletContextEvent event){
}

public void contextDestroyed(ServletContextEvent event){
}
}
[/code]

The deployment descriptor in this case would be,

web.xml

[code lang=”java”]
<web-app>

<listener>
<listener-class>net.javabeat.servlet30.newfeatures.SimpleServletContextListener
</listener-class>
</listener>

</web-app>
[/code]

Pluggability in Servlet 3.0

Web Fragments

Today, most of the modern popular frameworks such as Struts and Spring can be integrated easily with the Web Container for building robust applications. However, most of the time, the integration happens in such a way that the web.xml deployment descriptor has to be edited manually to configure framework specific servlet and listener classes. Have a look into the following code snippet,

web.xml

[code lang=”java”]
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

<servlet>
<servlet-name>Faces Servlet</servlet-name>
<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>Faces Servlet</servlet-name>
<url-pattern>/faces/*</url-pattern>
</servlet-mapping>

</web-app>
[/code]

The above web.xml will be familiar for someone who had used the JSF framework. We have used a framework-specific servlet called the FacesServlet in the above case for intercepting all the url requests with the pattern /faces/*. Same will be the case for another intergration frameworks such as Spring or Struts.

The problem with the current approach of the web.xml is that it is not modular. All the configuration details about one particular application is included in one single web.xml file. Assuming that if one single application is making use of one or more frameworks on top of it, there is no way to instruct the Servlet Container about the usage of other frameworks, the only option being is to edit the web.xml deployment descriptor. The Servlet 3.0 specification addresses this issue by introducing web fragments.

A web fragment can be considered as one of the segment of the whole web.xml and it can be imagined that one or more web fragments constitute a single web.xml file. A web-fragment can include all the possible elements that are applicable for the web.xml. Consider a sample web-fragment file,

web-fragment.xml

[code lang=”java”]
<web-fragment>
<servlet>
<servlet-name>myFrameworkSpecificServlet</servlet-name>
<servlet-class>myFramework.myFrameworkServlet </servlet-class>
</servlet>

<listener>
<listener-class>myFramework.myFrameworkListener</listener-class>
</listener>
</web-fragment>
[/code]

Typically a framework is bundled in the form of a jar file and it is the responsibility of that framework to define the web fragment file with the name web-fragment.xml in the META-INF directory of the jar file. During the application startup, it is the responsibility of the Container to scan the information that is found in the /META-INF/web-fragment.xml file available in the application’s classpath.

Programmatic support for adding web components

The specification also provides enhanced Pluggability where it provides options for adding servlets, filters, servlet mappings and filter mappings during the run time. Look into the following example code,

SimpleServletContextListener.java

[code lang=”java”]
package net.javabeat.servlet30.newfeatures;

import java.util.HashMap;
import java.util.Map;

import javax.servlet.ServletContext;
import javax.servlet.ServletContextEvent;
import javax.servlet.annotation.WebServletContextListener;

@WebServletContextListener()
public class SimpleServletContextListener {

public void contextInitialized(ServletContextEvent event){

ServletContext context = event.getServletContext();

String simpleServletName = "simpleServlet";
String simpleFilterName = "simpleFilter";

Map<String, String> initParams = new HashMap<String, String>();
initParams.put("param1", "value1");
initParams.put("param2", "value2");

String[] urlPatterns = new String[]{"/simple"};

context.addServlet(simpleServletName, "description for simple servlet",
"net.javabeat.servlet30.newfeatures.SimpleServlet", initParams, -1, false);
context.addServletMapping(simpleServletName, urlPatterns);

context.addFilter(simpleFilterName, "description for simple filter",
"net.javabeat.servlet30.newfeatures.SimpleFilter", initParams, false);
}

public void contextDestroyed(ServletContextEvent event){
}
}
[/code]

The code is pretty straightforward. It acquires the reference to ServletContext and makes use of the methods addServlet(), addServletMapping() and addFilter() for dynamically adding web components.

Asynchronous processing in Servlet 3.0

In a web application workflow, the client that initiates the request will be received by the Web Container and it is the responsibility of the Web Container to initiate the Servlet object by passing in the request and the response objects by calling in any of the request objects. Assume that the implementation code that tries to access external system, example a Database or a legacy system using JDBC or the JCA API’s is taking considerable amount of time for the execution to happen. In a normal environment the thread will get blocked and it will be made to wait until the data from the external system is available.

To avoid this waiting time or the block time, Servlet 3.0 adds support for asynchronous processing of request. The request can be made to put into asynchronous mode by calling the method ServletRequest.startAsync() that returns a AsyncContext object. It is also possible to specify the timeout duration by calling the ServletRequest.setAsyncTimeout() method. In this case, the response can be committed via two means, one is to call the complete() method that is defined on the AsyncContext object and the other way is when the timeout duration that is originally set on the request object has expired.

It is also possible to add asynchronous listeners to the request object to receive notifications whether the asynchronous operation is completed or the timeout has happened. The following code does the same,

SimpleAsyncListener.java

[code lang=”java”]
package net.javabeat.servlet30.newfeatures;

import java.io.IOException;

import javax.servlet.AsyncEvent;
import javax.servlet.AsyncListener;
import javax.servlet.ServletRequest;

public class SimpleAsyncListener implements AsyncListener{

public void onComplete(AsyncEvent event) throws IOException {
}

public void onTimeout(AsyncEvent event) throws IOException {
}
}
[/code]

To add this listener to the request object, use the following piece of code,

[code lang=”java”]request.addAsyncListener(new SimpleAsyncListener());[/code]

The same is reflected in the Web Servlet and the Servlet Filter annotations through the asyncSupported and asyncTimeout attributes,

SimpleServlet.java

[code lang=”java”]
package net.javabeat.servlet30.newfeatures;

import javax.servlet.annotation.InitParam;
import javax.servlet.annotation.WebServlet;

}
[/code]

Conclusion

The article covered the new set of annotations like @WebServlet, @ServletFilter that can be used to directly decorate the web components: Servlet and Filter, which could have done previously only through the usage of deployment descriptors. However, it should be noted that the usage of annotations is intended still for developers and not for the others who typically play the role of assembler or deployer. The Servlet 3.0 adds extensible support for plugging-in new frameworks or libraries without asking the developers to edit the deployment descriptor through web fragments. Finally the asynchronous nature of request processing, the possibility of adding asynchronous listeners along with the impacts in @WebServlet and @ServletFilter annotations were also discussed. Thank you for reading this article.

Reference for Servlet 3.0

JSR 315 – Servlet 3.0 Soecification

Servlet 3.0

October 2, 2008 by Krishna Srinivasan Leave a Comment

Can’t wait to see Servlet 3.0 in action. More details about the specification and the current status is available in its JSR homepage. The introduction of support for non-blocking I/O takes Java Servlets to a new level and this, in my opinion,is the most significant stride in Servlet specification since it was introduced. The benefits opened up by this new feature are several. Here are some I can think of –

If a request requires a remote call that can take significant time, servlet container does not have to maintain a dedicated thread as the web tier waits for the service to complete.
In case of a multi-part file upload, servlet container does not have to maintain a dedicated thread as the file is being uploaded over a slow network.
It is possible to have a Comet-style application, that keeps a client connection open and periodically pushes content on to client thus avoiding the need for client to poll for data.

Servlet 3.0 will be officially part of Java EE 6. The final version of Java EE 6 specifications are expected sometime this year and it would take a while for the application servers to be fully compliant with it. So we are looking at atleast a year or two before I can convince people in my company to use this. Sometimes, it’s so exciting to see a new technology introduced, but yet frustrating that it will take a while before I can really start using it. This is part and parcel of being in Java world and working in a cautious enterprise environment.

How to delete a cookie on server in a J2EE application

September 25, 2008 by Krishna Srinivasan Leave a Comment

There is no direct method offered by servlet API to delete a cookie on server side. This is how you can go about doing it.

Loop through the cookies in the request object to locate the one that you want to delete.
[code lang=”java”]for (Cookie cookie: request.getCookies()) {
if (USER_COOKIE_NAME.equals(cookie.getName())) {
return cookie;
}
}[/code]
Set the maxAge property of the cookie to 0. This results in cookie expiring with immediate effect as soon as the client receives the response.
Optionally, set the value property to empty string. This is not really required since the cookie is about to be expired. However, this adds a sense of a clean and complete erasure if the cookie being deleted carries some critical, secure data.
Add this cookie to response. The cookie will be gone once the response is sent back to client!
[code lang=”java”]view plaincopy to clipboardprint
cookie.setMaxAge(0);
cookie.setValue("");
response.addCookie(cookie);[/code]

Servlet Life Cycle

August 1, 2008 by Krishna Srinivasan Leave a Comment

Before start writing the servlet, it is important to know the life cylce of every servlet instance created. Read What is Servlet? tips to know about the servlet basics.

Servlet Life Cycle Methods

The following are the life cycle methods of a servlet instance:

init()
service()
destroy()

We will look into the each method in detail.

init()

This method is called once for a servlet instance. When first time servlet is called, servlet container creates instance of that servlet and loaded into the memory. Future requests will be served by the same instance without creating the new instance. Servlet by default multithreaded application.init() method is used for inilializing servlet variables which are required to be passed from the deployment descriptor web.xml. ServletConfig is passed as the parameter to init() method which stores all the values configured in the web.xml. It is more convenient way to initialize the servlet.

service()

This method is called for the each request. This is the entry point for the every servlet request and here we have to write our businesslogic or any other processes. This method takes HttpServletRequest and HttpServletresponse as the parameters. It is not mandatory to write this method, normally developers are interested in writing doGet() or doPost() methods which is by default called from theservice() method. If you override service(), it is your reponsibility to call the appropriate methods. If you are not overridden the service() method, based on the types of the request the methods will be called.

destroy()

This method will be called once for a instance. It is used for releasing any resources used by the servlet instance. Most of the times it could be database connections, Fill IO operations, etc. destroy() is called by the container when it is removing the instance from the servlet container.Servlet instance is deleted or garbage collected by the container only when the web server issues shut down or the instance is not used for a long time.

Single Thread Model

Although it is standard to have one servlet instance per registered servlet name, it is possible for a servlet to elect instead to have a pool of instances created for each of its names, all sharing the duty of handling requests. Such servlets indicate this desire by implementing the javax.servlet.SingleThreadModel interface. This is an empty, tag interface that defines no methods or variables and serves only to flag the servlet as wanting the alternate life cycle. A server that loads a SingleThreadModel servlet must guarantee, according to the Servlet API documentation, “that no two threads will execute concurrently the service method of that servlet.