The ‘/test’ in the URL will map to a servlet called test. The servlet will dispatch the request to a JSP for rendering that has the following scriplet code in it:

RequestURL: <%= request.getRequestURL() %> <br>
RequestURI: <%= request.getRequestURI() %> <br>
QueryString: <%= request.getQueryString() %> <br>
ServletPath: <%= request.getServletPath() %> <br>
PathInfo: <%= request.getPathInfo() %> <br>
PathTranslated: <%= request.getPathTranslated() %><br>
AuthType: <%= request.getAuthType() %> <br>
LocalAddress: <%= request.getLocalAddr() %> <br>
Method: <%= request.getMethod() %> <br>
RemoteUser: <%= request.getRemoteUser() %> <br>

this is the output generated:

RequestURL: https://localhost:8443/test/welcome
RequestURI: /test/welcome
QueryString: a=1&b=2
ServletPath: /test
PathInfo: /welcome
PathTranslated: C:\projects\testproj\out\artifacts\testapp_war_exploded\welcome
AuthType: CLIENT_CERT
LocalAddress: 127.0.0.1
Method: GET
RemoteUser: Steve

What is Flash Scope

Flash scope is a useful part of many web frameworks. It allows the use of the post/redirect/get design pattern to alleviate many of the problems associated with handling multiple submits or resubmission of data in browser requests to the server.

Flash scope is an additional scope to those provided in a standard Java Web application (page, request, session and application). Any attributes held in flash scope will be available for the duration of the current request, and the subsequent request too.

My Implementation

To implement flash scope in my application, I added a servlet filter that checks for request attribute names starting with ‘flash.‘. When it finds such an attribute, it ensures that it is made available in the subsequent request by temporarily storing it in the user’s session, and then reinstating it when the next request is received.

For example, to add a message to flash scope, just use the regular syntax for adding a request scoped attribute and let the fiter take care of it:

request.setAttribute("flash.message", "Here is the news...");

The above attribute can then be accessed in the redirect target JSP using EL or scriptlet syntax (omitting the ‘flash.‘ prefix):

${message}
or
<%= request.getAttribute("message")  %>

Here’s the code for the filter:

import javax.servlet.*;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
import java.io.IOException;
import java.util.Enumeration;
import java.util.HashMap;
import java.util.Map;

/**
 * Ensures that any request parameters whose names start
 * with 'flash.' are available for the next request too.
 */
public class FlashScopeFilter implements Filter {

    private static final String FLASH_SESSION_KEY = "FLASH_SESSION_KEY";

    @SuppressWarnings("unchecked")
    public void doFilter(ServletRequest request, ServletResponse response,
					FilterChain chain) throws IOException, ServletException {

        //reinstate any flash scoped params from the users session
		//and clear the session
        if (request instanceof HttpServletRequest) {
            HttpServletRequest httpRequest = (HttpServletRequest) request;
            HttpSession session = httpRequest.getSession(false);
            if (session != null) {
                Map<String, Object> flashParams = (Map<String, Object>)
									session.getAttribute(FLASH_SESSION_KEY);
                if (flashParams != null) {
                    for (Map.Entry<String, Object> flashEntry : flashParams.entrySet()) {
                        request.setAttribute(flashEntry.getKey(), flashEntry.getValue());
                    }
                    session.removeAttribute(FLASH_SESSION_KEY);
                }
            }
        }

        //process the chain
        chain.doFilter(request, response);

        //store any flash scoped params in the user's session for the
		//next request
        if (request instanceof HttpServletRequest) {
            HttpServletRequest httpRequest = (HttpServletRequest) request;
            Map<String, Object> flashParams = new HashMap();
			Enumeration e = httpRequest.getAttributeNames();
            while (e.hasMoreElements()) {
                String paramName = (String) e.nextElement();
                if (paramName.startsWith("flash.")) {
                    Object value = request.getAttribute(paramName);
                    paramName = paramName.substring(6, paramName.length());
                    flashParams.put(paramName, value);
                }
            }
            if (flashParams.size() > 0) {
                HttpSession session = httpRequest.getSession(false);
                session.setAttribute(FLASH_SESSION_KEY, flashParams);
            }
        }
    }

    public void init(FilterConfig filterConfig) throws ServletException {
        //no-op
    }

    public void destroy() {
        //no-op
    }
}

You can see from the listing, that the filter stores the flash scoped parameters in a session scoped map called FLASH_SESSION_KEY. Before the request is processed by the filter chain, the flash attributes are retrieved from the session and added to request scope; after the chain has finished, any new flash scoped parameters are stored in a new session scoped map.

Note that the attributes have the ‘flash.‘ prefix removed when added to the session scoped map – this not only ensures that they can be accessed using their ’short name’, but that they are only kept in the session for one extra request.

This approach is not Spring specific and should work with and Java Web framework. I’ve omitted the configuration for the filter as there are loads of examples of how to do this on the Internet already.

What is Open Session in View?

The Java Persistence API (JPA) allows an object oriented model to be mapped to a relational database. JPA is a standard specification for Java based Object Relational Mapping frameworks – in order to use JPA an underlying implementation must be available; the most common choice being Hibernate.

Both JPA an Hibernate support lazy loading of data to restrict the number of queries fired off to the database. In general this means that data will be loaded on demand when methods are called, on a loaded object, that require more data to be loaded. In order for this to work, the object that the method is called on must have been loaded by JPA and be part of the current running transaction.

In a Spring application, calls to demarcate transactions are generally handled by the Spring interceptors.Transactions are normally started when a method call is made on a Spring managed object and committed once that method call ends. This means that if a JSP page requests data by calling a transactional method on a Spring managed bean, then it can only access the data in that bean that has already been loaded within that call. Any calls for data that might be loaded lazily will fail because the object is no longer attached to a JPA transaction after that method call has returned.

Hibernate developers solved this problem using the Open Session in View design, which associates the active session (and hence it’s transaction) with the thread that makes the call. In this design, the transaction will be committed when the thread completed processing the request, rather than when a method call completes. This allows lazily loaded data to be loaded within the JSP page not just within Spring managed objects.

Providing Request Scoped Transactions

A standard way to intercept requests in any Java Web application is to use a web filter. Spring provide an out-of-the-box Web filters that implement the Open Session in View design for both Hibernate and JPA. We will see the JPA version here, but the Hibernate one works in just the same way; just change the class name in the configuration file.

In web.xml:

<filter>
    <filter-name>oemInViewFilter</filter-name>
    <filter-class>
        org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter
    </filter-class>
    <init-param>
        <param-name>entityManagerFactoryBeanName</param-name>
        <param-value>reportsEntityManagerFactory</param-value>
    </init-param>
</filter>

<filter-mapping>
    <filter-name>oemInViewFilter</filter-name>
    <url-pattern>*.jsp</url-pattern>
</filter-mapping>

The filter class is from the Spring framework libraries. The filter mapping, in this example, applies this filter to all URLs ending with ‘.jsp’; this means that all JSPs that retrieve a lazily loaded object form the service tier of the application are now free to read any data members from it – any unloaded data will be loaded from the database when calls are made to access it.

Be aware that the filter turns off the auto-flush behaviour of the standard entity manager. This means that any changes that are made to the data in the JSP will not be persisted. The filter can be configured to flush these if requested.

Finally, the init-param that’s provided to the filter is optional and can be used to explicitly name the entity manager factory that will be used. The example shows how to use an entity manager named ‘reportsEntityManagerFactory’ in the Spring configuration files; the default value for this is ‘entityManagerFactory’.

The Problem

The JSTL and EL greatly reduce the amount of Java code in a JSP and as a result, can be used improve its maintainability. The EL provides a syntax for working with Java objects and allows an object’s properties to be accessed using a simple dot notation. So, for example, in order to access the size of a collection, we might assume that we could use an expression like this:

${collectionName.size}

Unfortunately this will not work. In order to access a property in this way the object to which the property belongs must be implemented as a JavaBean component and it’s methods must adhere to the conventions described in the JavaBeans specification.

In short, to read the size property of a collection, the EL requires that the collection implements a getSize method; the bad news for us is that no such method exists in the Collections API.

Hack 1 – Use Scriptlets

The most common work-around to this problem is to simply fall back to using Java in a scriptlet in the JSP instead of the EL and to cast the request attribute to a collection:

<%=((Collection)request.getAttribute("collectionName")).size()%>

This work-around produces some quite ugly code and becomes even worse when we use it as part of another expression; for example, to test the size within an if tag:

<c:if test="<%= ((Collection) request.getAttribute("collectionName")).size() == 1 %>">
...
</c:if>

Hack 2 – Provide a JavaBeans Compliant Collection Wrapper

A more elegant solution is to wrap the Collection with an object that implements the Collection interface and delegates all calls to the real collection:

public class JSTLCollectionWrapper implements Collection {
    //the underlying collection that is being wrapped
    private final Collection realCollection;

    //constructor
    public JSTLCollectionWrapper(Collection c) {
        realCollection = c;
    }

    //implement Collection interface and delegate all calls to realCollection

    //provide a JavaBeans getter method for the size property
    public int getSize() {
        return realCollection.size();
    }
}

Then in your controller class, wrap all collections before adding them to the request or the users session:

Collection wrapped = new JSTLCollectionWrapper(realCollection);
request.setAttrubute("collectionName", wrapped);

The JSTL expressions can now access the size property of the collection as the wrapper class implements this according to the JavaBeans specification:

${collectionName.size}

The downside to this approach is that it requires you write the wrapper class, and that you must remember to use it wherever you add a collection as an attribute to an HTTP request or session in your controller classes.

The Best Practice Approach

Just so long as you’re using an application server that supports JSTL 1.1 or later (and you really should be), there’s a much neater solution available: use the functions tags.
The functions tags can be used in a JSP just like any other tag library, but rather than providing tags to use, the library extends the capabilities of the EL by providing some simple functions for you to use. Here’s how you can check the size of a collection using the functions tags:

<%-- declare that we intend to use the functions taglib --%>
<%@ taglib prefix='fn' uri='http://java.sun.com/jsp/jstl/functions' %>

<%-- use it --%>
${fn:length(collectionName)}

The first line here is just a standard taglib directive telling the application server that we would like to use the functions tags. The second line illustrates how the length function can then be used to return the size of a collection.

As you can see, the syntax is pretty simple, far less intrusive than using a scriptlet, and does not require any special coding in your controller classes. It also has the added advantage that it works for arrays too, and will even return the length of a String should you need to figure that out.
This solution retains much of its simplicity even when used in more complex expressions:

So there you have it. If you’ve been trying to figure out how to work with collection’s sizes in your JSPs, or maybe you’ve just been praying that Sun would rename the size method to getSize, then the functions tag library can offer a neat and simple solution to this common programming pitfall.