In this article we’ll be implementing the following functions, the code for which is available for download :

• Write a servlet that will dispatch the requests to our MVC handler class.
• In the MVC Handler, we’ll take a web request and invoke the appropriate controller method
• Take the result from the request mapped method and resolve it to a view which the user is forwarded to

Implementing the Servlet

Our servlet code takes incoming requests and delegates them to the injected MvcHandler instance.

@WebServlet(urlPatterns = "/demo/*")
public class DelegatingServlet extends HttpServlet {

    @Inject
    private MvcHandler mvcHandler;

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        doHandleRequest(req, resp, RequestMethod.GET);
    }

    protected void doPost(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        doHandleRequest(req, resp, RequestMethod.POST);
    }

    private void doHandleRequest(HttpServletRequest request, HttpServletResponse response,
        RequestMethod requestMethod) {

        mvcHandler.handleRequest(request.getPathInfo(),requestMethod,request,
            response,getServletContext());
    }
}

Our servlet uses the @WebServlet annotation to register the servlet for the /demo/* url path. It injects the instance of our MvcHandler class and uses it to handle the GET and POST requests. When we call the MVC handler, we have to pass in multiple objects that will be used by the handler. Looking ahead, we can see this is going to grow since we have controller methods, model values, outcomes and view names to pass around so we’ll create a new object called a RequestContext that will keep a hold of all these things and we can pass all those items around as a single object.

It makes our method calls look nicer with fewer parameters and we don’t have to keep adding parameters to methods for each new piece of information needed. Working with a single context means we can break the handler down to a specific set of steps with the product of each method (i.e. fetch model values) being held in the context and used in the next method. It also means we can convert it to an interface and/or abstract some of the information available to provide different implementations (i.e portal version). For now, we just need a basic version with a servlet context, request, response objects. We’ll also need to store the controller, the controller method and the outcome from that method.

public class RequestContext {

    private final ServletContext servletContext;
    private final HttpServletRequest request;
    private final HttpServletResponse response;
    private final RequestMethod requestMethod;
    private Object controller;
    private ControllerMethod method;
    private Object outcome;

    public RequestContext(ServletContext servletContext,
            HttpServletRequest request, HttpServletResponse response,
            RequestMethod requestMethod) {
        this.servletContext = servletContext;
        this.request = request;
        this.response = response;
        this.requestMethod = requestMethod;
    }

    //getters and setters omitted
}

Implementing the MVC Handler

Going back to our MVC Handler, the code in this class pulls everything together and orchestrates things as it receives calls from the servlet.

public class MvcHandler {

    @Inject
    private ControllerInfo controllerInfo;

    @Inject
    private ControllerMethodMatcher matcher;

    @Inject
    private BeanManager beanManager;    

	public void handleRequest(RequestContext context) {

		//find the controller method that best matches the request
		context.setMethod(matcher.findMatching(controllerInfo, context));

		if (context.getMethod() != null) {
			Object controller = locateController(context.getMethod().getControllerClass());
			context.setController(controller);
			// start executing the controller method
			executeControllerMethod(context);
			handleResponse(context);
		} else {
			throw new RuntimeException("Unable to find method for "
					+ context.getRequestMethod() + " request with url "
					+ context.getPath());
		}
	}

    private void handleResponse(RequestContext context) {
        if (context.getOutcome() instanceof String) {
            String outcome = (String) context.getOutcome();
            String view = "/"+outcome+".jsp";
            context.forwardTo(view);
        }
    }

    private Object locateController(Class<?> controllerClass) {
          //returns a bean of type controllerClass from CDI
    }

    private void executeControllerMethod(RequestContext context) {
       //executes the controller method on the controller
    }
}

We inject our instance of ControllerInfo which holds all the controller methods and the handleRequest() method is called from the servlet when receives a web request. In order to service the request it takes the following steps :

• Find a matching controller method for this request.
• Locate the controller
• Execute the controller method on that controller instance saving the outcome returned from the method.
• Handle the correct response back to the user.

For now, we are just assuming the controller method returns a string that indicates the view name which we forward to. I added a method to handle forwarding on the request context object.

Matching Methods

The ControllerMethodMatcher is an interface that can be used to locate a controller method in the list of controller methods that matches the incoming request info held in the request context

public interface ControllerMethodMatcher {
    ControllerMethod findMatching(ControllerInfo info,RequestContext context);
}

Our default implementation of this is really simple for now. We iterate through our list of controller methods and check that the request type matches the request method of the incoming request. If it does, then as long as the url path starts with the controller level prefix and ends with the method level suffix, then it is a match. Because we already sorted the controller methods in order of the larger expressions first, we know that the first match we come across is the best for now.

public class DefaultControllerMatcher implements ControllerMethodMatcher {

    public ControllerMethod findMatching(ControllerInfo info,RequestContext context) {
        for (ControllerMethod method : info.getControllerMethods()) {
            if (matches(method, context)) {
                return method;
            }
        }
        return null;
    }

    protected boolean matches(ControllerMethod methodToTest, RequestContext context) {
        String path = context.getPath();
        boolean result = methodToTest.matchesRequestMethod(context.getRequestMethod())
            && (methodToTest.getPrefix() == null || path.startsWith(methodToTest.getPrefix()))
            && (methodToTest.getSuffix() == null || path.endsWith(methodToTest.getSuffix()));
        return result;
    }
}

We can override this class, and re-implement the matches method later on and since we pass in the RequestContext we will have all sorts of information available to us to determine the best match.

Executing the Controller Method

We can just use reflection to execute the controller method instance for now. We assume that there are no params for now, that will come later.

private void executeControllerMethod(RequestContext context) {
	Method javaMethod = context.getMethod().getMethod();
	Object outcome = null;
	try {
		outcome = javaMethod.invoke(context.getController());
	} catch (Exception e) {
		e.printStackTrace();
	}
	context.setOutcome(outcome);
}

Seeing it in action

Finally we can put it all together so we can see it in action in a web application. For now our MVC code is in our web project to make integrating it easier. We can later extract the MVC code to a stand-alone module to use as a library in other projects. We’ve already set up a controller and our servlet, now we just need to create a couple of pages based on the string returned from the mapped methods. If we run the application now and go to a url such as http://localhost:8080/mvcdi/demo/person/list we will get an error message because listPeople.jsp doesn’t exist. We’ll create the following simple jsp pages so we can display something in the browser. Each page just consists of the boilerplate structure and some text that indicates which page we are on.

<html>
  <head>
    <title>View Person</title>
  </head>
  <body>
    View Person
  </body>
</html>

We do this for the following pages in the root of the web directory.

• viewPerson.jsp
• listPeople.jsp
• updatedPerson.jsp
• editPerson.jsp (see below for additional changes)

The one different page is the editPerson.jsp page where we want to put a form containing only a button so we can issue a POST request which maps to the method on the controller that handles the POST request from the editPerson.jsp page and navigates to the updatedPerson.jsp page in response.

<html>
    <head>
        <title>Editing Person</title>
    </head>
    <body>
        Editing Person
        <form method="post">
            Some Form Here<br/>
            <input type="submit" value="Update" />
        </form>
    </body>
</html>

If we go to http://localhost:8080/mvcdi/demo/person/edit and click the submit button, we get sent to the page that tells us we just updated someone because that is the page returned from the controller method for the edit path with a POST request method.

You can download (mvcdi_part2.zip) the code for this as a maven project that can run on any Java EE 6 container and has been tested on both JBoss AS 7 and Glassfish 3.1.1.

This wraps up the second installment of this series on implementing Spring MVC in Java EE 6 and CDI and covers the bulk of the request mapping so we can direct our web requests to controller methods and ultimately to specific pages. Next time we’ll look at providing model data to the pages.

Interestingly, there’s nothing like Spring MVC for Java EE which is a shame because it is a really good framework. So in this series of articles, I’ll be covering different aspects of implementing Spring MVC on CDI with the caveat that this won’t be an exact compatible replica. I’ll be implementing just enough of each feature to demonstrate that it can be done, but I’ll leave enough room so that with more work, it can be a more accurate implementation. It goes without saying that these articles assume you are familiar with Spring MVC 3 using annotations and at least a little bit familiar with CDI. I’ll also mention that the code listed in the articles only contains the code relevant to the implementation for demonstration purposes. I’ve removed a lot of the null checks and other defensive programming code to make things more readable but they are still present in the final code.

In this first part, we will start by laying all the dull ground work as we capture the metadata from the MVC annotations in the following steps :

• Define our MVC annotations
• Define a class to hold our request mapped methods
• Write some code to extract the request mapped methods from a given class and store the metadata

The MVC annotations

To get started we implement the controller and request mapping annotations which are based on the Spring MVC versions. @Controller marks our classes as MVC controllers that implement MVC methods. Each method that can be mapped to a URL is mapped with the @RequestMapping annotation.

@Target({ ElementType.TYPE,ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
public @interface Controller {
}

The request mapping annotation has two attributes (for now), the default value which contains an array of paths that are mapped to this controller or method. For now, we will implement simple path matching, the url must start with the controller path and end with the path defined on the method. We can change to a more complex wildcard/Ant path matching implementation if we want to later. The other attribute on the request mapping is an array of RequestMethod types that indicates the type of requests we want to map to this controller and method. For now, we’ll just deal with POST, GET and DELETE request types :

public enum RequestMethod {
    POST,GET,DELETE
}

Now we can define our request mapping annotation :

@Target({ ElementType.TYPE,ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
public @interface RequestMapping {

    String[] value() default {};
    RequestMethod[] method() default {};
}

Armed with our new annotations, we can go ahead and create our first controller :

@Controller
@RequestMapping("/person/")
public class PersonController {

    @RequestMapping("list")
    public String doListPeople() {
        return "listPeople";
    }

    @RequestMapping("view")
    public String doViewPerson() {
        return "viewPerson";
    }

    @RequestMapping(value="edit",method=RequestMethod.GET)
    public String doGetEditPerson() {
        return "editPerson";
    }

    @RequestMapping(value="edit",method=RequestMethod.POST)
    public String doPostUpdatePerson() {
        return "updatePerson";
    }
}

For now, our controller methods return a String which can be used to determine the final view to render.

The MVC CDI Handler

Originally, I considered writing this as a CDI extension but felt that it wasn’t a good match and instead chose to create a managed MvcHandler bean that will be invoked by the servlet and will lazily initialize its own configuration post construction. This led to a more modular design since I could make the MvcHandler the center of the implementation and it let me write it in a purely managed environment saving me from having to deal with some of the limits extension have compared to managed beans.

Technically, when a web request comes in, we could get a list of controllers and iterate through them to find a matching controller and then search for a method on that controller that matches our request. However, I’m extracting and storing all that metadata on startup since it is more efficient and will allow for more expansion later on. When we start examining different types of metadata, it will get ridiculous doing it all at run time. Also, it lets us optimize a bit since we could have several matches, but some will be better matches than others so we will always need to compare all the controller methods each time a request comes in. Pre-reading it lets us also presort the controller methods into best-fit-first.

Extracting Controller Metadata

We’ll create a class called ControllerInfo that holds the metadata for the controllers. It does this by taking the controller class and iterating through its methods and seeing if they have the request mapping annotation on them. If they do, those methods are added to a list of ControllerMethod objects. This object holds info about a specific mapped method on a controller :

public class ControllerMethod {
    private final String prefix;
    private final String suffix;
    private final RequestMethod[] requestMethod;
    private final Method method;

  //getters and setters
}

The prefix is determined from the request mapping path on the controller class, and the suffix is determined from the request mapping on the method. The request method value indicates which kinds of request methods this method can be mapped to (GET or POST requests). The Method object is a java reflection Method instance that we can use to not only define the class method that is mapped, but also reference the declaring class for when we need to locate the controller bean. Since the path value can be an array of strings if a particular method has multiple paths in the value then there will be mulitple ControllerMethod entries, one for each path as the suffix. However, we don’t split up multiple request method values instead opting to store them as they are as an array.

@Controller
@RequestMapping("/somePath/")
public class MyController {

   @RequestMapping(value={"page1.do","page2.do"},method={GET,POST})
  public void someMethod() {
     ...
  }
}

The above class results in two entries :

The reason for this is it lets us optimize the path matching based on the best match first by sorting based on the length of the suffix path. Again, we can improve this ordering later on by using a better path matcher.

Now we’ve a place to store the controller method information, we can implement the ControllerInfo class which contains the list of Controller method instances:

@ApplicationScoped
public class ControllerInfo {

    private final List<ControllerMethod> controllerMethods = new ArrayList<ControllerMethod>();

    private static final String[] DEFAULT_MAPPING_PATHS = new String[] { "" };

    public static final AnnotationLiteral<Controller> CONTROLLER_LITERAL = new AnnotationLiteral<Controller>() {
        private static final long serialVersionUID = -3226395594698453241L;
    };

    @Inject
    private BeanManager beanManager;

    @PostConstruct
    public void initialize() {
        Set<Bean<?>> controllers = beanManager.getBeans(Object.class,CONTROLLER_LITERAL);
        for (Bean<?> bean : controllers) {
            add(bean.getBeanClass());
        }
        sortControllerMethods();
    }

    private void add(Class<?> clazz) {
    }
}

The initialize method is invoked when this bean is first created. As we’ll see later, this bean is injected into the MvcHandler so this method is only called when needed. It uses the CDI API to locate all beans with a controller qualifier annotation and calls the add(Class<?> clazz) method for each controller class. Finally it makes a call to sort our list of ControllerMethod instances.

In the add method, for the given controller class, we iterate through its methods and see if we can add them as a request mapped method.

private void add(Class<?> clazz) {
    if (clazz.isAnnotationPresent(Controller.class)) {

        Method[] methods = clazz.getMethods();
        String[] controllerPaths = null;

        RequestMapping rm = clazz.getAnnotation(RequestMapping.class);

        if (rm != null) {
            controllerPaths = rm.value();
        }

        // if no paths are specified, then default to one blank path so we always add it
        if (controllerPaths == null || controllerPaths.length == 0) {
            controllerPaths = DEFAULT_MAPPING_PATHS;
        }

        // add methods for each mapped path at the controller level
        for (String prefix : controllerPaths) {
            for (Method m : methods) {
                addMethod(prefix, m);
            }
        }
    }
}

private void addMethod(String prefix, Method javaMethod) {

    RequestMapping mapping = javaMethod.getAnnotation(RequestMapping.class);
    if (mapping != null) {

        String[] paths = mapping.value();

        // if these are blank, fill with defaults
        if (paths == null || paths.length == 0) {
            paths = DEFAULT_MAPPING_PATHS;
        }

        for (String path : paths) {
            controllerMethods.add(new ControllerMethod(javaMethod, prefix,path, mapping.method()));
        }

    }
}

The addMethod function will check for a request mapping annotation on the method, extract the metadata and store it in the list.

This about wraps up the first installment which covers the extraction of request mapped methods and storing them for use later on. Next time we’ll start coding our servlet and core MVC handler that will let us make web requests and invoke the mapped methods on our controller before displaying the appropriate web page.

My Personal Choices

For me personally, nothing does Web Applications better than JSF backed by Java EE 6. A year ago I would have said Seam, but Java EE 6 now carries most of the Seam functionality. Java EE 6 with Seam 3 sprinkled in for good measure will rock. (if you think Java EE 6 sucks for not being whole until it has Seam 3 added, think of it more like adding jQuery to your web pages). I do like Wicket, but for me, it’s one of those that sits in the middle and does a bit of both. It’s like riding a bike to the mailbox (only a little bit of overkill), or to the store (better than walking, but still with limits). However, it is a very viable alternative.

For web site type projects, I would look for a framework that is more client oriented since people will want to start leveraging the advancements with HTML 5 and Javascript. I would probably use Spring MVC or at a stretch, possibly Grails. Primarily because it offers a development structure that is not so dissimilar to using JSF, and can include Spring Web Flow for more statefulness. At the same time it lets you get under the hood more with CSS, HTML and JavaScript if you choose to. It also gives you some more deployment options without taking features away.

Note that these are merely my personal choices and their selection says nothing about the choices made by anyone else any more than choosing to drive a Ford is being critical of someone driving a Honda. Similarly, if you think Fords suck, you should have at least have a good reason for believing so, other than you couldn’t drive one before you learned how to.

Conversational Fundamentals

Let’s start with a fairly descriptive and steady paced description of what conversations are and what they are not. Some of these behaviors are probably more figurative that literal. This mainly applies to Seam, but is also similar to CDI.

Conversations in Seam are like buckets that hold conversational data. A user session has a list of conversation contexts each identified by a conversation Id. A conversation is either long running or temporary and even when you are not in a long running conversation, you are using a temporary conversational context or bucket. The only difference between a long running conversation and a temporary conversation is the boolean longRunning flag on the conversation instance. When you start a conversation, all that happens is the longRunning flag on the conversation is set to true. When you end the conversation, the longRunning flag is cleared. There is no destruction of conversational objects and no clearing out of the conversation. Abandoned long running conversations sit in the conversation list until they time out. Note that in JCDI (JSR 299), the long running flag has been renamed to a isTransient flag on the conversation.

Components that are scoped to the conversation are still held in the conversation context regardless of whether it is long running or temporary. The only difference with a long running conversation is that the id for the conversation is propagated from one page to the next. When the id is propagated, that same conversation ‘bucket’ is used by the next page and the objects that were in the previous page are accessible in the new page. In each request, Seam determines if the conversation is long running, and if so, it passes the conversation id to the next page as a parameter. Obviously, this propagation only takes place with faces requests, or GET requests that have special handling like manual conversation propagation or you are using the Seam JSF controls that provide GET requests with automatic conversation propagation.

When rendering a new page, at some point Seam will need to access the conversational context. It does this by looking to see if the request contained a conversation id and if so, looking up the existing conversation context instance for that id. Otherwise, it obtains a new conversation instance with a new conversation Id. When there is no long running conversation, no id is propagated so each page obtains a new conversation instance and Id. When we start a long running conversation Seam will automatically propagate the conversation id from one page to the next for us which is how we write applications with multiple pages using the same conversation.

When you end a conversation, the longRunning flag is set to false and Seam no longer propagates the id from one page to the next. However, when you end a conversation on one page, Seam will still propagate the conversation to the next page one last time. This allows us to carry things like faces messages and any other data over the conversation boundary. This next page gets to use the same conversation instance that just finished outside of the conversation boundary. It has a number of benefits as well as some important consequences that can cause many problems that are tricky to track down.

If you end your conversation and set the before-redirect attribute to true the conversation is ended before the redirect so the conversation id is not propagated and the new page starts with a fresh conversation context. The problem with this is that since there is no propagation of the conversation, faces messages (and any other information you wanted to carry to the new page) is not propagated either. This is to be expected since you explicitly specified that you wanted to end the conversation before the new page.

There are also times when Seam will propagate the conversation from one page to the next when it is not long running. If a redirect is taking place, then Seam promotes the conversation to long running temporarily so the conversation id parameter is passed to the redirect. The conversation is then demoted again to a temporary conversation. This allows items such as faces messages to propagate so you can show messages even after a redirect.

One useful way of seeing which conversation you are using is to add Conversation = #{conversation.id} to your template so you can see what conversation id the page is using. This way you can see whether or not the conversation has propagated and whether you are using the same value from the previous page. If the conversation id on two pages is the same, they are using the same conversation instance and sharing data.

Hopefully, this section has provided enough of an overview into Seam conversations, cleared some of the misconceptions up and will make understanding some of the conversational pitfalls easier.

Dirty Data

When you end a conversation, the conversation instance contains multiple pieces of data. Let’s take the scenario of editing a widget, and clicking save or cancel and being taken back to the widget view page. Our Seam page uses a factory method to generate the #{widget} instance from our WidgetHome bean. We may edit the instance, and post back the changes, and then decide to cancel our changes. At this point, our widget in the conversation is dirty, it has changes made to it that we have cancelled. If we do nothing and just go back to the view page, the conversation will be re-used since we propagate that ended conversation id over one last time. The #{widget} references in the view page will refer to our existing dirty instance in the re-used conversation. Since the variable exists in the conversation already, Seam won’t call the factory method to get a fresh instance. As a result our view page shows the dirty instance with all our modifications.

This problem can be solved in a couple of different ways, each with its own problems. The simplest is to use before-redirect=true when ending the conversation. This way our view page won’t use the dirty data from the ended conversation and it starts with a fresh conversation. This may be a problem though if you are passing the widgetId parameter from the previous page. Pages.xml lets you easily add parameters to redirects, but pageflows don’t. It also means that you won’t be able to pass any other data over such as a message to say you have cancelled changes. Another similar, but more forceful, way of doing this is just to have a non-faces ‘cancel’ link on your edit page that takes you straight to the edit page with a GET request and passes in the widget Id. In this scenario, the conversation is abandoned since we used a link and it will not propagate the conversation or the associated dirty data over with it, nor can you pass any cancellation messages over.

The other method is to let the view page re-use the conversation, but when the user cancels the changes, actually refresh the entity that has been changed. You create a cancel method on the entity home bean which is called when the user cancels their changes and it will refresh the entity so it is no longer dirty. This has the benefit of causing minimal disruption, but if you have a long chain of objects that ended up dirty, making sure you refresh them all can be tricky.

Stale Data

The stale data problem is similar to the dirty data problem except the problem occurs within the same conversation and without ending it. If we have some data in a conversation that depends on other values in the conversation, when those values change, we have to make sure we update our data, otherwise it will become stale. For example a paginated list of sales orders from on an EntityQuery means that we need to get a new set of results when we click next or previous. However, if the results of the query are outjected from the query bean and referenced as #{orderList} in the JSF page, then we will see the stale data problem. The first time we enter the page, the variable #{orderList} doesn’t exist, so Seam calls the factory for #{orderList} which returns the list of the first 10 results. Our datatable shows the list of results using the variable orderlist.

<h:dataTable value="#{orderList}">
  <!-- Columns Here -->
</h:dataTable>

The user clicks next in the paginator which does a postback, increases the firstResult value and causes a refresh on the result list referenced by the entity query to show the next 10 results. The page is rendered but the displayed results are exactly the same. We are still looking at the first 10 rows. Why? Because the orderList context variable is used by the view to obtain the list of orders. When the page is rendered the second time, JSF looks for the value of #{orderList} and finds it already exists in the conversational context even though it contains the first 10 results, and not the second 10. Seam has no reason to call the factory method to obtain the latest values. In essence, we have two sets of results, the original set which is referenced by the orderList seam variable, and the current set which is the correct list of results and is held by the query bean.

We have two ways of fixing this problem. The first is to change the value our data table is referencing so it is always referencing the result set on the query bean directly.

<h:dataTable value="#{orderQuery.resultList}">
  <!-- Columns Here -->
</h:dataTable>

With this code, there is no El expression used that can become stale. When the page is re-rendered the table will get the results from the order query directly each time ensuring that the most up to date values are used. This is the easiest solution but it cannot be used if you are using the DataModel annotation since Seam requires you to use the outjected data model variable. In such cases refer to the second solution which is to invalidate the orderList variable when we refresh the search results. This is fairly easy, but requires us to override the refresh method in the entity query. When we refresh the list of orders, we simply remove the #{orderList} context variable. i.e.

@Override
public void refresh()
{
    super.refresh();
    Contexts.removeFromAllContexts("orderList");
}

This means that when the user causes a refresh of the query data, the variables referencing that data will be ejected from all contexts and the next time that value is requested in a JSF page, the appropriate Seam factory will be called to get the most up to date result set.

Starting a conversation

Even starting a conversation can be a problem. In most cases, we utilize the join="true" attribute to gloss over the fact that we are going into a page that requires a conversation with or without a conversation already started. When we hit our target page, we know that we will be in a conversation, either a newly started one, or an existing conversation. We may not care which except that not considering our conversation start and end points has side effects. Using the join attribute is not a substitue for thinking about conversation demarcation.

First is the issue of old data where a new page may re-use data from the last page because they share the conversation. For example, we are viewing a widget and the widget instance is loaded into the temporary conversation. 10 minutes later, we click edit which takes us to the widget edit page and starts a long running conversation. The edit page needs an instance of a widget which it already has from the view page, but this instance of a widget is 10 minutes old and has been edited by another user since you loaded the view page and therefore, you need to do a refresh. This problem arose without us even starting a long running conversation in the view page. The answer here is to ensure that you are always starting with a fresh conversation instance when you go in to the edit page. The easiest way to do that is to use propagation="none" on the link to edit the widget, or just use a plain old GET link.

If a page is meant to start a conversation and also start a pageflow then you cannot enter that page with an existing conversation. If you do, the page will join the existing conversation and the pageflow will not start. Pageflows can only be started with a fresh conversation. Note that initially a page may be simple enough that you don’t need a pageflow and you could ignore conversation demarcation, but if you later start a pageflow on that page, you could end up with all sorts of headaches as invoking that page from different places may or may not start the pageflow depending on whether the page you were on previously had a long running conversation.

Menus

Always consider your menus and their links and what pages they will be used in. They could be called from pages where there may or may not be a long running conversation. Consider whether that conversation is propagated or not. Typically (and luckily) most links in menus are to top level items and thus conversation propagation is never really required which means you can just never propagate it. Propagation is mostly task centric and therefore is more likely to appear in the main page itself rather than a general application wide menu.

One other problem I found was with rich menu items which only allow an action on the menu item. Typically to end or demarcate a conversation, you would need an s:link or s:button since only these Seam specific controls were are aware of the concept of conversation propagation. Since our menu is shared across all pages if we were in a pageflow, we could end up with Illegal Navigation issues since we don’t account for global menu navigation in our pageflows. Alternatively, we might be in a conversation and calling a page that starts a new conversation with a pageflow so we need to end the conversation before we get there so we can start the new conversation and also the new pageflow. In a nutshell, we need to end any current conversation then re-direct to a new page where we will start a new conversation. We also need to be able to do this from a JSF action since some menu components require actions instead of allowing you to add links.

One solution to this is to use a navigator component that will perform these tasks for us and we just pass in the view-id that we want to go to.

@Name("navigator")
@Scope(ScopeType.STATELESS)
public class Navigator {

	public void gotoView(String view) {

		if (Conversation.instance().isLongRunning()) {
			Conversation.instance().end(true);
		}

		Redirect.instance().setViewId(view);
		Redirect.instance().execute();
	}

}

With this, we can define our action methods as #{navigator.gotoView("/startBookingProcess")} and when that menu item is selected, it will end the conversation and perform the redirect so on our new page we can start a new conversion and pageflow.

Conversational Best Practices

These are best practices that I’ve found working with Seam and conversations in general. Obviously, it’s a personal thing, and some people may disagree with me on them, but these rules have served me and my team well.

Always determine where a page fits in terms of conversations and always treat that page the same way. For example, edit and view pages I tend to isolate from other conversations. I tend to only use the temporary conversation for the view page so if you click refresh, it reloads the data which is really what you want, a refreshed view of what you are looking it. Any links to a view (or edit) page do not propagate the conversation at all.

I always start conversations in pages.xml since this provides a single common place to do it. I’ve never really used the annotations since it requires knowledge of the target page to know which method you need to call. To edit a widget, with pages.xml you can just go to /widgetEdit.seam?widgetId=234 as opposed to calling a specific method annotated with @Begin.

Hope this has helped guide you through some of the complexities of conversations in Seam. Once you understand the basic principles, it makes it much easier to figure out why something isn’t working quite right, and some of these bugs relating to stale and dirty data can be subtle and sneaky.

IDE Support – I would like to get as much IDE support as possible for auto completion, code validation and general helpfulness.

Resume Building – How much demand is there for the skills? I’m looking to bolster my skills that have wide adoption in the industry. As this is an important factor, it also means I probably won’t be choosing a framework that I am already very familiar with. I’ll be using job trends and opinion to determine the industry support for the frameworks. I know job sites aren’t the best measure, especially since many ads are stuffed with buzzwords so they appear in searches even if there is no JSF, JAXB or JAX-WS involved. However, the fact that they are included at all indicates some kind of market penetration of the technology.

Ajax Support – How well does it support Ajax natively out of the box as opposed to requiring third party libraries and are there de-facto standard libraries for that framework if they are needed.

Templating / Layout – How are pages built and organized to enable reusable HTML without using include statements everywhere or some other mechanism which will require every page to be edited if the layout is changed. I think facelets is the best page layout library out there as it pulls the template into the page and then pushes the content from the page into the template making separate files optional. Tiles requires separate definition files and does a similar thing outside of the page being rendered. Sitemesh is non invasive and works by decorating existing pages as they are sent to the client. In terms of writing actual pages, the choices are Jsp, Velocity and Freemarker, of which JSP and Velocity are the two most in demand.

Completeness – How much is in the framework out of the box without requiring additional libraries for core functionality. Obviously, you are going to need libraries for things like data access, but the framework should be able to put text in a page without requiring third party libraries. One other aspect of this is how easy it is to get up and running without having to get different pieces configured and talking to each other. Some frameworks discussed here like Spring MVC and JSF are not meant to be complete frameworks but a framework onto which to build other frameworks (like Servlets). In these cases, the frameworks are expanded by third party libraries so completeness is not so much a factor here. Third party libraries integrated as part of the stack is acceptable (i.e. Sitemesh in Grails and Richfaces in Seam).

Custom Paginated Tables with Sortable Columns – This is my barrier for determining how powerful and easy a framework is to use. Simple CRUD is trivial to write, it’s like hello world for the web so I usually go for a more robust litmus test by writing some pagination code. Action frameworks require you to chug all the parameters backwards and forwards and handle your own binding and determining whether a page was selected or next/previous was clicked while Component frameworks handle most of that for you. For the same reason, clickable columns can be a real pain. For bonus points, how easy is it to implement multiple paginated / sortable tables?

Statefulness – Can we integrate some kind of stateful mechanism in there (i.e Spring Web Flow) cleanly? There are a few scenarios where I will need a stateful workflow in the application.

Third Party Support and integration – One annoying aspect of java web development is all the pieces and parts that need to be strung together and then you have to get them to play nicely. This is really about the path of least surprise, and not having to deal with issues because I add libraries that don’t have special mechanisms for working with each other.. I.e Spring MVC embraces Tiles, but how much of a hassle is it to incorporate Velocity with Tiles? This issue is also somewhat redundant for those frameworks that include built-in solutions for most needs.

The application is going to be moderate in size, but hopefully growing as time goes on. For that reason, I’m looking for something flexible enough to grow and refactor later on. Initially, I’m also looking for something lightweight and will be looking to deploy it on Tomcat primarily due to ease of hosting.

Action or Component Based

I find Action frameworks are great for catalogs and simple CRUD pages but when you start getting to more complex web applications pages, things get much tricker. Take for example a search page with 10 search parameters, suddenly you find yourself having to attach 10 parameters to the next/previous/first/last result links or using javascript funkiness to modify form contents to change the form state and post the form. Add column ordering and things get pretty messy quickly. In my mind, For a web application, any search pages (or other pages that require pagination or other common interface elements) should be trivial to write within minutes. Obviously, if you are Google and your main business is that one search page, you can afford to spend a little more time on it and be as choosy as you like on how to implement it. However, it never fails to amaze how much code people will write to create a single page demonstrating how to do some simple function in a non-reusable way. User interface elements like pagination and column ordering should be totally reusable.

The Contenders

Here are the contenders in no specific order

• Seam with JSF
• Wicket
• JSF
• Grails
• Spring MVC with JSP
• Spring MVC with JSF

First lets look at the job trends for these different frameworks :

spring java, ejb java, jsf java, "spring mvc" java, wicket java, seam java, grails java Job Trends

spring java jobs – ejb java jobs – jsf java jobs – "spring mvc" java jobs – wicket java jobs – seam java jobs – grails java jobs

We can see a sort of multi-tier system in place for different frameworks. Spring and EJB both rank up there as first tier technologies. I’ve already had quite a bit of experience with both of these but Spring is at an advantage with regards to being lightweight and running in tomcat without having to worry about setting up an embedded EJB container. Writing something with EJB 6 might be a possibility, but I think it more likely I’ll try and use Spring.

Now lets consider the view frameworks :

jsf java, "spring mvc" java, wicket java, seam java, grails java Job Trends

jsf java jobs – "spring mvc" java jobs – wicket java jobs – seam java jobs – grails java jobs

Seam / JSF

I’ve had a lot of experience with these two so it’s easy to comment on. Great IDE support (probably the best), great out of the box support, but it can feel foreign to use on Tomcat where it doesn’t offer such a rich a developer experience. Great Ajax support, but not so great for the resume since I already have a lot of experience with Seam and there are very few Seam jobs out there.

JSF

Despite using Seam a lot, writing a straight JSF application is still quite different and poses a number of challenges. It might be a interesting using just JSF but I have most of that ground covered with my existing JSF work. JSF is in-demand though and this might be an opportunity to use it with other frameworks such as a Spring/Hibernate/JSF combination. It has great Ajax support with multiple frameworks available, but no decent IDE support even though JBoss Tools works well on plain JSF apps without Seam. It may also get frustrating since I’ll be having constant reminders of how easy things are when you use Seam. Facelets is a great templating framework, if not the best, and I’d probably go to JSF 2.0 so I can use annotated beans. For statefulness, I could add in Orchestra and pagination should be simple with JSF although I think Seam (or JBoss-El) added ways to call methods (with parameters) on beans passed in to facelets which made it really easy. I haven’t been able to duplicate that with in JSF or Spring Faces which could be a problem. One annoyance of JSF is the inability to suppress validation when you post the form back but don’t want to save it which you may want to do as part of a web flow where you want to save the contents, go to another page, come back and finish your data entry. The only solution is to manually perform validation when the form is finally saved and not use JSF validators which is a limitation and I don’t thing this was fixed in JSF 2.0.

Wicket

Wicket is a great component based framework with good ajax support, a fine grained stateful architecture and because of it’s emphasis on the java language, good IDE support. Some people don’t like the heavy use of java code to build web pages, but it’s a personal thing and I do enjoy it. However, the only thing holding it back for me is the poor industry adoption with very few Wicket jobs.

Grails

I tried to get back into Grails and again, I hit a number of snags. It’s a great framework, but I find it can be problematic. The IDE support was basic and I often had to clean the eclipse project then the grails project so it wouldn’t choke on old classes lying around. Netbeans also has Grails support, but was prone to hanging when you want to restart the server. It also lacked the refactoring / renaming features present in eclipse. I also found problems in the framework itself such as not being able to model embedded classes that contained a reference to another entity. Other times, inexplicably, when I called person.save() nothing would happen, no error, no messages, nothing. I don’t doubt it was my fault and something I did, but it is off putting and frustrating in a framework that won’t tell you when you have a syntax error.

Grails and Wicket seem like polar opposites in some ways. Wicket is all about type safety and strict java code checked by the IDE. Grails on the other hand doesn’t often know when you make a mistake because its a dynamic language. Developers shouldn’t have to write tests just to make sure you didn’t make any typo’s in your classes, people have spent a number of years and millions of dollars evolving IDEs to solve that very problem.

The dynamic language is all very nice, and Grails is a framework but when I’m building furniture, I don’t start out with aflat pack plywood cabinet and slowly replace each piece with half inch mahogany with hand cut dovetail joints in the name of being rapid and agile (umm, Agile Wordworking, there’s an idea). I can see the point, and for the most part, Grails is unobtrusive but I think for me, on this project, I’d rather start out with a workbench and some planks of mahogany and craft it from scratch.

Ajax support is excellent and it also has many plugins which are easy to install and use. Writing taglibs is a breeze and very intuitive. Even pagination was fairly simple and I especially liked the paginator tag that takes a map of parameter values to include on all the previous/next/page links. Again, things are scarce on the job front for Grails, but being such a unique and productive tool I think there is a great future for Grails which lowers the importance of current trends.

Grails also supports Spring Web Flow but I’m not sure it allows the use of flow scoped persistence contexts. Sitemesh is used for templating and offers a lot of features out of the box. Overall it’s very impressive and definitely still a contender.

Spring MVC with JSP

This is probably the one I was most eager to tackle as I think this one probably has the most potential. Spring and JSP have been largely adopted within the industry, but are they any good? I think Spring MVC is excellent, especially with the new Spring 2.5 Controller annotations and Web Flow integration. As usual with Spring, it provides a lot of flexibility and it sits on the Core Spring Framework. For templating, I can use Sitemesh, Tiles, and it includes support for velocity and free marker. It appears that using both Tiles and Velocity together isn’t straightforward resulting in this third party plugin to solve the problem.

Spring MVC doesn’t have any ajax support, Chapter 13 – Web MVC Framework of the Spring reference documentaton doesn’t even mention the word Ajax. Spring Web Flow has Ajax support but it requires the use of Tiles (or some other compatible templating library) for specifying page fragments to update. This is also requires that pages be designed in such a way that the Ajax updatable pieces are clearly defined in the page definition which is outside of the page being designed. With Richfaces you can create a fragment in the page just by using an output panel tag and giving it a name. Another problem with Spring Web Flow is the inability to use an Open Session In View alongside the Flow Managed Persistence context which means having to work around Lazy Initialization Issues in other ways. On the plus side though, you can make validation optional in Spring Web Flow if you are using the Spring Validators and not JSF.

Spring MVC with JSF / Spring Faces

If I couldn’t find a way to reconcile the problems with Spring MVC and JSP, this would be my backup as it solves a number of problems with using Spring MVC and JSP. It fixes the Ajax and templating issues since I can use a JSF based Ajax framework (IceFaces or Richfaces) and Facelets for superior templating. The only problems here is a resource issue for JSF and the fact that I have already worked with JSF extensively. However, I have found Spring Faces to be a great library to use with some nice extensions. While there are only a few jobs explicitly mentioning Spring Faces, there are many jobs involving Spring and JSF. While spring web flow de-couples your view from the back end, it can be a little too decoupled. For example, within a flow, to call a method from a command button and refresh some data requires you to call the method and return an action string that would trigger the refresh of the data in the web flow. In Seam, you can get away with just calling the method and then refreshing the data. Spring Web Flow, forces you to decouple that which makes for a lot more work when you have multiple links that can trigger a refresh of the data. It also doesn’t fix the open session in view / flow managed persistence context clash. Writing JSF pages outside of a web flow means having to work directly with Spring beans as Jsf backing beans as opposed to dealing with Spring Beans through the web flow. This isn’t a big deal though, it just means you have two separate styles of writing code. Even though Spring Web Flow lets you suppress validations for flow transitions, It doesn’t have any effect when you are using JSF for the view, only when you are using Spring validations.

Summary

Ultimately, it boils down to Grails or Spring MVC with JSP and probably Tiles and if I can’t find a solution there, Spring MVC with JSF. I f career/employment was not a factor, I would pick Wicket with Spring in a second, however, as I’m looking to bolster my resume and make sure my bona fides are in order for the more popular technologies.

All in all, it’s a difficult choice, but I’d love to get some more thoughts on the matter. I’m sure there are plenty of opinions on frameworks out there in The java community

(update : If you have already read the previous version only chapter 5 is new and has the Wicket example and final comparison.)

Enjoy,

HTML
Single Page HTML
PDF

I recently had to start another project using Spring Web Flow and found myself banging my head against a brick wall to get the web flow stuff set up and to request the page properly. As a result, I decided to write up my results as a quick how-to for other developers should they find themselves in the same situation and also as a reference for myself the next time I need to start a Spring Web Flow project using Spring Faces from scratch.This article is meant more of a “here’s-how” as opposed to a “how-to” or an “explain-why” so we’ll move at a quick pace with little explanation.

For the IDE, I used Eclipse 3.4.1 with Spring IDE plugins version 2.2.1, with Spring 2.5.6 (with dependencies) and Spring Web Flow 2.0.5. You should be able to use SWF 2.0.7 without any problems. For dependencies, I mostly used the ones provided with Spring except for a few, the details of which are included below. Hibernate was used as the JPA implementation and it was all deployed on Tomcat 6.0.18.

Getting Started

U started by installing Eclipse and then the Spring plugins. I created a new workspace, and added Tomcat as a server, and created a new dynamic web project. I right clicked on the project to add the Spring nature to the project.
The project will be arranged with multiple Spring configuration files for the database, spring web flow and the main applicationContext.xml to include them in. Flows will be in a directory under /WebContent/WEB-INF/flows.
I started off setting web.xml up with the faces pieces and the Spring MVC dispatcher servlet.

	<!-- The main config file for this Spring web application -->
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>/WEB-INF/applicationContext.xml</param-value>
	</context-param>

	<!-- Use JSF view templates saved as *.xhtml, for use with Facelets -->
	<context-param>
		<param-name>javax.faces.DEFAULT_SUFFIX</param-name>
		<param-value>.xhtml</param-value>
	</context-param>

	<!-- Enables special Facelets debug output during development -->
	<context-param>
		<param-name>facelets.DEVELOPMENT</param-name>
		<param-value>true</param-value>
	</context-param>

	<!-- Causes Facelets to refresh templates during development -->
	<context-param>
		<param-name>facelets.REFRESH_PERIOD</param-name>
		<param-value>1</param-value>
	</context-param>

	<!-- Loads the Spring web application context -->
	<listener>
		<listener-class>
			org.springframework.web.context.ContextLoaderListener
		</listener-class>
	</listener>

	<!-- Serves static resource content from .jar files such as spring-faces.jar -->
	<servlet>
		<servlet-name>Resources Servlet</servlet-name>
		<servlet-class>
			org.springframework.js.resource.ResourceServlet
		</servlet-class>
		<load-on-startup>0</load-on-startup>
	</servlet>

	<!-- Map all /resources requests to the Resource Servlet for handling -->
	<servlet-mapping>
		<servlet-name>Resources Servlet</servlet-name>
		<url-pattern>/resources/*</url-pattern>
	</servlet-mapping>

	<!-- The front controller of this Spring Web application, responsible for handling all application requests -->
	<servlet>
		<servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
		<servlet-class>
			org.springframework.web.servlet.DispatcherServlet
		</servlet-class>
		<init-param>
			<param-name>contextConfigLocation</param-name>
			<param-value></param-value>
		</init-param>
		<load-on-startup>1</load-on-startup>
	</servlet>

	<!-- Map all /spring requests to the Dispatcher Servlet for handling -->
	<servlet-mapping>
		<servlet-name>Spring MVC Dispatcher Servlet</servlet-name>
		<url-pattern>/spring/*</url-pattern>
	</servlet-mapping>

	<!-- Just here so the JSF implementation can initialize, *not* used at runtime -->
	<servlet>
		<servlet-name>Faces Servlet</servlet-name>
		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>

	<!-- Just here so the JSF implementation can initialize -->
	<servlet-mapping>
		<servlet-name>Faces Servlet</servlet-name>
		<url-pattern>*.jsf</url-pattern>
	</servlet-mapping>

	<welcome-file-list>
		<welcome-file>index.html</welcome-file>
	</welcome-file-list>

At the top of this web.xml file, we indicate that our primary Spring bean config file is called \WEB-INF\applicationContext.xml so we navigate to that folder (it’s in the WebContent folder) and right click and add a new Spring Bean Definition. We also add two other Spring Bean definitions in the same place called dbConfig.xml and flowConfig.xml. These files are defined below :

/WebContent/WEB-INF/applicationContext.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema
/beans/spring-beans.xsd">

	<import resource="dbConfig.xml" />
	<import resource="flowConfig.xml" />
</beans>

/WebContent/WEB-INF/dbConfig.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:aop="http://www.springframework.org/schema/aop"
	xmlns:tx="http://www.springframework.org/schema/tx"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd
		http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx.xsd">

	<bean id="entityManagerFactory"
	class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
		<property name="jpaVendorAdapter">
			<bean
	class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
				<property name="showSql" value="true" />
				<property name="generateDdl" value="true" />
				<property name="databasePlatform"
	value="org.hibernate.dialect.MySQLDialect" />
			</bean>
		</property>
		<property name="dataSource" ref="dataSource" />

	</bean>

	<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
	destroy-method="close">
		<property name="driverClassName" value="com.mysql.jdbc.Driver" />
		<property name="url" value="jdbc:mysql://localhost:3306/dbName" />
		<property name="username" value="someUser" />
		<property name="password" value="somePassword" />
	</bean>

	<bean id="transactionManager"
	class="org.springframework.orm.jpa.JpaTransactionManager">
		<property name="dataSource" ref="dataSource" />
		<property name="entityManagerFactory" ref="entityManagerFactory" />
	</bean>

	<tx:annotation-driven />

	<bean
	class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor" />

</beans>

/WebContent/WEB-INF/flowConfig.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:webflow="http://www.springframework.org/schema/webflow-config"
	xmlns:faces="http://www.springframework.org/schema/faces"
	xsi:schemaLocation="

http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

http://www.springframework.org/schema/webflow-config

http://www.springframework.org/schema/webflow-config/spring-webflow-config-2.0.xsd

http://www.springframework.org/schema/faces

http://www.springframework.org/schema/faces/spring-faces-2.0.xsd">

	<!--Executes flows: the central entry point into the Spring Web Flow system-->
	<webflow:flow-executor id="flowExecutor">
		<webflow:flow-execution-listeners>
			<webflow:listener ref="jpaFlowExecutionListener" />

		</webflow:flow-execution-listeners>
	</webflow:flow-executor>

	<!-- The registry of executable flow definitions -->
	<webflow:flow-registry id="flowRegistry"
	flow-builder-services="facesFlowBuilderServices">
		<webflow:flow-location path="/WEB-INF/flows/testFlow/testFlow.xml"></webflow:flow-location>
	</webflow:flow-registry>

	<!-- Configures the Spring Web Flow JSF integration -->
	<faces:flow-builder-services id="facesFlowBuilderServices"
	development="true" />

	<!--
		Installs a listener that manages JPA persistence contexts for flows
		that require them
	-->
	<bean id="jpaFlowExecutionListener"
	class="org.springframework.webflow.persistence.JpaFlowExecutionListener">
		<constructor-arg ref="entityManagerFactory" />
		<constructor-arg ref="transactionManager" />
	</bean>

	<!-- Maps request URIs to controllers -->
	<bean
	class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">

		<property name="mappings">

			<value>
				/testFlow=flowController
			</value>
		</property>
		<property name="defaultHandler">
			<!--
				Selects view names to render based on the request URI: e.g. /main
				selects "main"
			-->
			<bean
	class="org.springframework.web.servlet.mvc.UrlFilenameViewController" />
		</property>
	</bean>

	<!-- Handles requests mapped to the Spring Web Flow system -->
	<bean id="flowController"
	class="org.springframework.webflow.mvc.servlet.FlowController">
		<property name="flowExecutor" ref="flowExecutor" />

	</bean>

</beans>

Since we are using JPA, we need to include a persistence.xml file to the classpath in src/META-INF/persistence.xml.

<?xml version="1.0" encoding="UTF-8"?>
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://java.sun.com/xml/ns/persistence

http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"

	version="1.0">

    <persistence-unit name="default" transaction-type="RESOURCE_LOCAL" />

</persistence>

Now we need to add a faces-config.xml in the same location.

/WebContent/WEB-INF/faces-config.xml

<?xml version="1.0" encoding="UTF-8"?>
<faces-config version="1.2" xmlns="http://java.sun.com/xml/ns/javaee"
	xmlns:xi="http://www.w3.org/2001/XInclude"
	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-facesconfig_1_2.xsd">

	<application>
		<el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
		<view-handler>com.sun.facelets.FaceletViewHandler</view-handler>
	</application>
</faces-config>

We’ll also add a html page that redirects to a jsf page immediately. Since we are using facelets, we’ll also throw in a template to work from. In the WebContent folder, we’ll add the templates directory to contain our page layout.

WebContent\templates\template.xhtml

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
                      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
	xmlns:ui="http://java.sun.com/jsf/facelets"
	xmlns:h="http://java.sun.com/jsf/html"
	xmlns:f="http://java.sun.com/jsf/core">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

  <title><ui:insert name="title">untitled</ui:insert></title>

</head>

<body>
  <h:messages globalOnly="true" />

  <ui:insert name="title">Title Here</ui:insert>

  <ui:insert name="body" />
</body>
</html>

Now to add our two pages that will initially launch is into a JSF page.

/WebContent/index.html

<html>
<head>
  <meta http-equiv="Refresh" content="0; URL=home.jsf">
</head>
</html>
</textarea> <code>/WebContent/home.xhtml</code> <pre name="code" class="xml">
<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
                      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
	xmlns:ui="http://java.sun.com/jsf/facelets"
	xmlns:f="http://java.sun.com/jsf/core"
	xmlns:h="http://java.sun.com/jsf/html"
	template="templates/template.xhtml">

	<ui:define name="body">
		<h:form>

			<h:outputText value="Hello From JSF!" />

		</h:form>
	</ui:define>
</ui:composition>

One more configuration file we need is for Log4j to get rid of the warnings that it has not been set up correctly. The properties file goes in the src directory.

/src/log4j.properties

### direct log messages to stdout ###
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.Target=System.out
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n
log4j.rootLogger=info, stdout
log4j.category.org.springframework=WARN
log4j.category.org.hibernate=WARN

Now let’s look at libraries. There are a bunch of libraries that are needed since we haven’t added any yet.

One reason I downloaded the latest JSF version was because I was having problems with the JSF version I was using. The SpringBeanELResolver was being ignored at run-time, it didn’t even blink if I set it to an undefined class name, however the Spring Delegating variable resolver was working, but the IDE was saying it was deprecated. Once I upgraded to JSF 1.2_11, the EL resolver worked fine. I’m wondering if an old 1.1 JSF version had crept in there.

Depending on where you end up deploying your application (i.e.Glassfish), you may end up having to remove some of these libraries if they are already installed on the server. In this case, I was using Apache 6.0.18 with a clean install, and therefore with no libraries added to the server.

Creating a Flow

Now we should have a working application all ready to go. To test this, we’ll add a little code and a test page just to verify that everything is working ok. Create a new class called MessageHolder in a package called swfproject. This is a simple class that contains a string that can be set and retrieved from our pages.

/src/swfproject/MessageHolder.java

package swfproject;

public class MessageHolder implements Serializable {

	private String text = "Hello From the Message Holder";

	public String getText() {
		return text;
	}

	public void setText(String text) {
		this.text = text;
	}
}

Now we define the bean in the /WEB-INF/applicationContext.xml so we can call the bean from a regular jsf page, or a flow page.

	<bean name="springMessage" class="swfproject.MessageHolder">
		<property name="text" value="This was defined in Spring" />
	</bean>

In the home.xhtml page, we add the following line to the page, somewhere between the ui:define tag on the page to display the message

Message is : #{springMessage.text}

If you start Tomcat, assuming you have already attached the project to the server if you are using an IDE, and go to http://localhost:8080/projectName/ you should redirect to home.jsf and it should the message that was defined in Spring.

Now let’s add a simple flow called testFlow. If you look in the flowConfig.xml file, there is already a mappings property where we already defined /testFlow=flowController. This means that when this url is requested, the flowController bean instance deals with it.

We need to create a new directory under /WebContent/WEB-INF/flows/, and in there, we need to create a directory called testFlow. In that, we add a page called testFlow.xhtml and testFlow.xml. This is the view and the flow defined respectively.
/WebContent/WEB-INF/flows/testFlow/testFlow.xml Flow

<?xml version="1.0" encoding="UTF-8"?>
<flow xmlns="http://www.springframework.org/schema/webflow"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:faces="http://www.springframework.org/schema/faces"
	xsi:schemaLocation="http://www.springframework.org/schema/webflow

http://www.springframework.org/schema/webflow/spring-webflow-2.0.xsd"

	start-state="testFlow">

	<var name="flowMessage" class="swfproject.MessageHolder" />
	<view-state id="testFlow">
		<transition on="post" to="testFlow" />
	</view-state>
</flow>

/WebContent/WEB-INF/flows/testFlow/testFlow.xhtml View

<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
                      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
	xmlns:ui="http://java.sun.com/jsf/facelets"
	xmlns:f="http://java.sun.com/jsf/core"
	xmlns:h="http://java.sun.com/jsf/html"
	template="/templates/template.xhtml">

	<ui:define name="body">
		<h:form>
			<h:outputText value="This is a test flow" />
			<br />
			Message From Spring = #{springMessage.text}<br />
			Message From Flow = #{flowMessage.text}<br />
			<h:inputText value="#{flowMessage.text}" style="width:200px" />
			<h:commandButton action="post" value="Update" />
 		</h:form>
	</ui:define>
</ui:composition>

Now if you go to http://localhost:8080/app_name/spring/testFlow (Remember to replace app_name with your project name) you should see the page we have made as part of our flow. It displays the message from the springMessage instance of the MessageHolder that contains the message from spring. I now also displays the instance from the flow which contains the default message displayed since the flow variable hasn’t had the text property changed. Also, the URL should change to http://localhost:8080/app_name/spring/testFlow?execution=e3s1 or something similar with the execution on the end. This page demonstrates that we will have access to the spring beans, as well as access to variables defined in a flow which is where flowMessage is defined. You can edit the message and click post to change the flowMessage text value. You can open the link up in two browser windows or tabs and see how the two values can be edited independently, and the flowMessage variable is scoped to the flow in the browser.
From this point, you can go ahead and move on with the application all you like. You can change the flow mappings, put in wildcarded flow locations, even get started with trying out Spring MVC (as I plan to). Hope you find this useful as a quick start guide to getting a JSF Spring Web Flow project up and running, as well as defining flows and calling them.

HTML
Single Page HTML
PDF

(Updated 1/19/2009 : Changed links to point to the whole set of articles)
HTML
Single Page HTML
PDF