How to avoid IllegalStateException in java servlet?

The root cause of IllegalStateException exception is a java servlet is attempting to write to the output stream (response) after the response has been committed.

It is always better to ensure that no content is added to the response after the forward or redirect is done to avoid IllegalStateException. It can be done by including a ‘return’ statement immediately next to the forward or redirect statement.

Example servlet source code snippet:

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
if("success".equals(processLogin())) {
response.sendRedirect("menu.jsp");
return; // <-- this return statement ensures that no content is adedd to the response further
}
Note: This same scenario of IllegalStateException is applicable in JSP also.

Servlet JSP Communication

getServletConfig().getServletContext().getRequestDispatcher(“jspfilepathtoforward”).forward(request, response);

The above line is essence of the answer for “How does a servlet communicate with a JSP page?”

When a servlet jsp communication is happening, it is not just about forwarding the request to a JSP from a servlet. There might be a need to transfer a string value or on object itself.

Following is a servlet and JSP source code example to perform Servlet JSP communication. Wherein an object will be communicated to a JSP from a Servlet.

Following are the steps in Servlet JSP Communication:

1. Servlet instantiates a bean and initializes it.
2. The bean is then placed into the request
3. The call is then forwarded to the JSP page, using request dispatcher.

Example Servlet Source Code: (ServletToJSP.java)

public class ServletToJSP extends HttpServlet {
02. public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
03.
04. //communicating a simple String message.
05. String message = "Example source code of Servlet to JSP communication.";
06. request.setAttribute("message", message);
07.
08. //communicating a Vector object
09. Vector vecObj = new Vector();
10. vecObj.add("Servlet to JSP communicating an object");
11. request.setAttribute("vecBean",vecObj);
12.
13. //Servlet JSP communication
14. RequestDispatcher reqDispatcher = getServletConfig().getServletContext().getRequestDispatcher("/jsp/javaPapers.jsp");
15. reqDispatcher.forward(request,response);
16. }
17.}

Example JSP Source Code: (javaPapers.jsp)

<-html>
02.<-body>
03.<%
04. String message = (String) request.getAttribute("message");
05. out.println("Servlet communicated message to JSP: "+ message);
06.
07. Vector vecObj = (Vector) request.getAttribute("vecBean");
08. out.println("Servlet to JSP communication of an object: "+vecObj.get(0));
09.%>
10.<-/body>
11.<-/html>

Session Tracking

There are three typical solutions to this problem.

1 Cookies. You can use HTTP cookies to store information about a shopping session, and each subsequent connection can look up the current session and then extract information about that session from some location on the server machine. This is an excellent alternative, and is the most widely used approach. However, even though servlets have a high-level and easy-to-use interface to cookies, there are still a number of relatively tedious details that need to be handled:

* Extracting the cookie that stores the session identifier from the other cookies (there may be many, after all),
* Setting an appropriate expiration time for the cookie (sessions interrupted by 24 hours probably should be reset), and
* Associating information on the server with the session identifier (there may be far too much information to actually store it in the cookie, plus sensitive data like credit card numbers should never go in cookies).

2 URL Rewriting. You can append some extra data on the end of each URL that identifies the session, and the server can associate that session identifier with data it has stored about that session. This is also an excellent solution, and even has the advantage that it works with browsers that don't support cookies or where the user has disabled cookies. However, it has most of the same problems as cookies, namely that the server-side program has a lot of straightforward but tedious processing to do. In addition, you have to be very careful that every URL returned to the user (even via indirect means like Location fields in server redirects) has the extra information appended. And, if the user leaves the session and comes back via a bookmark or link, the session information can be lost.

3 Hidden form fields. HTML forms have an entry that looks like the following: . This means that, when the form is submitted, the specified name and value are included in the GET or POST data. This can be used to store information about the session. However, it has the major disadvantage that it only works if every page is dynamically generated, since the whole point is that each session has a unique identifier.

Servlets provide an outstanding technical solution: the HttpSession API. This is a high-level interface built on top of cookies or URL-rewriting. In fact, on many servers, they use cookies if the browser supports them, but automatically revert to URL-rewriting when cookies are unsupported or explicitly disabled. But the servlet author doesn't need to bother with many of the details, doesn't have to explicitly manipulate cookies or information appended to the URL, and is automatically given a convenient place to store data that is associated with each session.