(Edit : I renamed this post so it doesn’t seem like Spigot is just for Seam, Spigot can be used with different frameworks or without any at all. However, I wrote this post since Spigot is so familiar to the Seam EntityQuery that it should be easy for Seam users to get the idea)

Seam developers should become familiar with Spigot concepts fairly quickly since they are very similar to those found in the Seam EntityQuery which was one of the main inspirations for the framework. If you imagine taking the entity query class and splitting it in two, one part to keep hold of state and the other to actually fetch the data. The stateful part is the Paginator that keeps track of what the current ordering of the data is, what is the current page and how big the pages are. The stateless part takes the Ejbql and the pagination information and returns a subset of the data. Now imaging that the data provider has the JPA pieces taken out and replaced with an abstract fetchResults method. This method is implemented in subclasses for specific data providers for text files, sql queries, jpa queries, native jpa queries, xml files, comma delimited or just an in memory dataset.

I also abstracted the concepts of parameterization and parameter resolution so you can have parameters on data providers that are no t query based and your parameters can be resolved using different mechanisms such as EL, reflection, a map, or using custom parameter resolution.
So really, for Seam developers, its like a Seam EntityQuery that doesn’t just use JPA, but uses any kind of data source you want but still returns just a list of objects.

Spigot works nicely with CDI and there is even a demo of it in the distribution that uses JSF and was generated using the Weld maven archetypes. Also, there is a Seam Jpa Dataset Adapter that you can use as a direct replacement for the EntityQuery which will adapt the entity query calls to the underlying data provider calls so you can have a seam-less transition if you want to switch over. This is still a little in-progress, but works. The one area that isn’t implemented is the sorting, which may not be possible, but I still need to add in the methods to the adapter even if they don’t do anything. The other issue is of course the configuration of the query from components.xml using the Seam Framework tags. However, you can define the query using regular component xml tags to define the Ejbql, restrictions and page sizes.

Two things to note if you start using Spigot in place of the entity query. All rows are returned by default, and you need to specify both a select statement and a count statement. I separated those two out so you can put join fetch phrases in the select statement without it breaking the count statement. There is an init method that you can use to set both of these statements for a class type.

It’s been a while since I’ve posted anything new as I’ve been busy with a new Open Source software project called Spigot. It’s a java library that sits between your application code and your data sources (Hibernate, JPA, JDBC or any arbitrary source of data) and helps with things like pagination and sorting using a common interface so you can switch out data providers and use alternatives.

For query language data providers, Spigot also facilitates excluding restrictions from WHERE clauses when parameters are resolved to null. Parameters are handled using parameter resolvers so there is more than one way to parameterize the query including EL expressions, reflection or a value map on the data provider.

Spigot also provides a few other add-ins like converting any dataset into an in-memory dataset that can itself be paginated and sorted and shared across an application (such as commonly used data in a web application). The IndexedDataProviderCache can give you random access into a dataset with caching and look ahead loading. This lets you hook a dataset with thousands of rows up to a Swing JTable with an instant response and a very small memory footprint since it doesn’t need to load all the objects at once as the provider will load the records as needed and cache the results. This is demonstrated in the Swing Demo in the download. There are also demos for Wicket and CDI with JSF.

You can ready about why I created Spigot in the documentation

Spigot is currently hosted on Project Kenai, where you can download the release, view documentation online or read about 10 ways Spigot helps developers.

In some weird web app which lets you pick a person and then put costumes on them, you might have a main page where you select the person, and then in separate browser windows you can pick different outfits for that person. You put the selected person value in a different conversation so the value of #{selectedPerson} is local to the conversation allowing multiple selected people in different browser windows. This overcomes the limitations of the session which allows only one value for #{selectedPerson}

However, if you had that conversation open in multiple windows or tabs so you can compare different costumes on that person, there would only be one value of #{selectedCostume} for the conversation shared between all windows. As you select a costume in one window, it would affect all the other windows as they share the variable in that conversation. Using nested conversations would allow the conversation to have different values for the selected costume under the same parent conversation with the same selected person.

Taking it further you could select the person in the top level conversation, select the costume in the nested conversation, and then you could have multiple windows open with further nested conversation letting you pick different shoes to go with that costume. Also, if you change the person in the top level conversation, it will change the selected person for all windows using that conversation or any of its nested conversations.

I’m not sure there is a great need for nested conversations, I’ve never really used them or found the need and I don’t think users open that many browser windows or tabs to create different logic paths within a conversation. I think it is acceptable to limit the data isolation to a single conversation level.

Developers can be finnicky at times, and find topics such as heavy app servers and framework lock-in (even to the standards) to be more of an issue than they should be. On this level, Seam really lost out since it was based on standards, ran on an app server (although it ran in many environments), and there was a degree of lock-in as a Seam project, not much more than any other framework based project.

However, Seam itself is an excellent framework and it certainly helped make JSF 1.2 a more usuable framework. Most of those holes are now patched permanently with JSF 2.0 which logically would mean that JSF 2.0 is up to par with JSF 1.2 plus Seam. Well, not quite, although JSF has come a long way I think the one reason Seam soothed a lot of pains was not just down to the fact that it made JSF 1.2 usable. It was also because of the additional functionality it provided above and beyond the average web framework. First was the conversation scope which not only provided a more versatile scope than request and session scope, but also laid the foundation for resolving other problems. With conversation scope we are able to easily handle multiple browser windows/tabs, including independent page flows within those tabs as well as providing Workspace management. Second, it was a full stack solution with a (softly) predefined set of libraries providing different pieces of the stack. No more piecing together different technologies and getting it to work properly, you got everything in one bundle to create stateful rich web applications.

There are probably interesting times ahead for Seam with the evolution of JEE 6 and the release of CDI. EJB 3.1 continues the trend of making EJBs easier than ever, JSF 2.0 makes it a more pleasant experience (now with AJAX), and Weld now provides us not only with a standards based, contextual dependency injection framework, and also makes conversational applications possible out of the box. Many of the great things Seam offered is now available in JEE 6 as part of a standard stack. This is an exciting prospect for developers and makes the JEE 6 stack far more attractive, but doesn’t it also reduce the need for Seam?

JEE 6 isn’t simply Seam standardized, nor is it even Seam lite. There are still a number of larger features in Seam not available in JEE and rightfully so since there are a number of functions which are too specific to be standardized. This particularly applies to the features that span across multiple technologies that fit into neither the CDI, JPA, or JSF libraries. Interestingly, the Seam name would also still be suitable as a framework used to stitched them all together which was originally the concept for Seam. JSR 299 offers not only a firm base onto which you can implement those features, but allows implementing them as expansion plugins to the CDI framework through which most of Seam 3 will be implemented.

My hope is that Seam 3 will consist of a set of fairly independent plugins that can be added to applications in the form of CDI / JSF plugins so there is less lock-in and more of a sense of adding Seam where it is needed. This way we don’t need to start with a Seam application from the start, we can start with a standard plain old JEE 6 web application using EJB, CDI, JSF, JPA and add the Seam features as needed. Another benefit here is that when we add Seam components in such a manner, we are not adding framework code, we are adding features that works on top of our existing framework since the base code for such features is already in the JEE stack. This has worked well in the past on various different platforms, specifically in Java with JSF and the different component libraries available for it.  I think this softer approach to integration will make it more appealing in the long run, . While JEE 6 may have lower barriers to entry for this functionality, JBoss have shown they are able to compete in such environments, for example on the JSF front they have previously competed with different stateful and conversational frameworks.

Overall, things are looking very interesting for the future of JEE 6, and its progress has sparked a resurgent interest from developers. JSR 299 fills an important gap in JEE giving developers a powerful and feature filled standard web stack which can be extended easily. While it may remove some of the need for Seam, it also offers more opportunities for Seam to integrate with the new stack effortlessly and build on it with more features.

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.

(note This post relates to both the milestone 2 and beta versions of Netbeans 6.8 which I have been tinkering with over the duration of this article being written.)

The download for Netbeans 6.8 comes with Glassfish v3 which implements JEE 6 including JSF 2.0 and JPA 2.0.

Glassfish now has really fast hot deployment so you can change a line of code, save it, and it re-deploys instantly which in my opinion, this is a huge productivity booster. This isn’t limited to Netbeans, the eclipse plugins also provide this feature, and it works with pretty much any framework. I tried it with Wicket and Spring MVC and it was fantastic to get a wicket error where I had forgotten to add a component, so I go back to the java page code, add the component, refresh my browser and it works. Glassfish now has support for JEE 6 so you can make a pojo a local EJB just by adding the @stateless annotation to it. You can also deploy EJBs in war files as well without needing the whole EAR setup. One problem I did see was that when you used the EAR project setup with an EJB and War project, the hot deploy didn’t appear to work as well. Changes to the war file didn’t appear to redeploy, maybe because it is the EAR file that is deployed and not the war. However, still fantastic stuff.

Netbeans 6.8 beta was released in the last week or so. Feature-wise it is a great product with better tooling for JSF, including JSF 2.0, facelets support, and auto-completion for JSF backing beans in the JSF page. It also includes support for JEE 6, EJB 3.1, JPA 2.0 and development with Glassfish v3. It also improves upon the existing Maven support by providing for mavenized Ear projects.

While the features are impressive, Netbeans still seems hindered by performance issues and some minor bugs (although it is a milestone/beta release). Personally, I found this release no more sluggish that other releases although some people in the forums have had worse experiences. Netbeans strength has always been that it offers one standard solution without the plugin nightmares that eclipse has. While Netbeans has plugins they are more like installable features, they have a higher granularity than Eclipse plugins which is more like DLL hell. That said, I use Eclipse at work and it is always hard to shift from one keyboard mapping to another, and Eclipse does seem faster without the intermittent pauses. However, right now, Netbeans is a superior product in terms of features, especially for a JSF developer. I’d keep an eye out for the 6.8 final release to see how it comes out, and give 6.8 milestone 2 a go just to enjoy the experience if you are interested in using a standards based stack because thats obviously where the Netbeans folks are focused.

One big issue I have with Netbeans is the oddness of some of the key mappings. I think in nearly every application I use I press Alt+F and then C to close the currently edited document. Whether is it in MS Office, Borland Delphi, Eclipse, Firefox, while in the file menu, the C key always closes the currently open document you are editing. In Netbeans, it closes the currently edited project which means suddenly my project disappears when I want to close an edited file. Another is the use of Ctrl+Space for invoking auto completion which in Netbeans sends focus to the project manager or something like that. Sure, I can change the keymappings, such as to the Eclipse profile, but then I’m using some arbitrary weird key mapping which isn’t Netbeans and it isn’t completely the same as Eclipse. It is probably this way for legacy reasons, but some of these key presses are de facto standards.

Lastly, we come to JSF 2.0 which was forged from JSF 1.2 and the litany of complaints about it. The JSR group looked at the solutions out in the wild that already work around those problems (many of which were written by people in that very group) and incorporates those fixes in a standard JSF API type of way. Primarily we have the dropping of JSP as the default view in exchange for the Facelets / JSF templating solution. This also lent itself very well to easier component creation including no-code components. There is now zero configuration required except for the servlet in web.xml and managed beans can now be defined using annotations. Navigation which also used to be in the faces-config.xml is also more convention of configuration. Another big request was the inclusion of AJAX awareness in the JSF lifecycle . It provides the bare minimum features that 3rd party developers can build upon using the standard API instead of their own AJAX solutions. There is better support for GET requests and page parameters as well as invoking actions on page requests which is a feature often used in Seam.
There is also some performance boosts with regards to re-working state saving and the resource access mechanisms have been improved a great deal.

Also noteworthy is the inclusion of Weld CR 1 which is the reference implementation of JSR 299 – Java Contexts and Dependency Injection from JBoss. Admittedly, I haven’t really gotten round to taking a look at it, but from what I have seen and read so far, it looks like it fills some gaps in the JEE 6 platform and is up to par with the new found simplicity and strength that JEE 6 is promoting right now.

Overall, this is a pretty exciting set of tools and framworks and well worth a look if you are interested in adopting a standards based stack.

@Name("conversationListener")
@Scope(STATELESS)
public class ConversationListenerBean implements ConversationListener {

	@Logger
	private Log log;

	@In
	private Conversation conversation;

	@Observer(value="org.jboss.seam.beginConversation")
	public void observeConversationStart() {
		log.debug("Conversation #0 Started",conversation.getId());
	}

	@Observer(value="org.jboss.seam.endConversation")
	public void observeConversationEnd() {
		log.debug("Conversation #0 Ended",conversation.getId());

	}
}

Just add this bean into your project and it will automatically log when you start and end conversations.

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

public class LogPhaseListener implements PhaseListener {

	public long startTime;

	private static final LogProvider log = Logging
			.getLogProvider(LogPhaseListener.class);

	public void afterPhase(PhaseEvent event) {
		if (event.getPhaseId() == PhaseId.RENDER_RESPONSE) {
			long endTime = System.nanoTime();
			long diffMs = (long) ((endTime - startTime) * 0.000001);
			if (log.isDebugEnabled()) {
				log.debug("Execution Time = " + diffMs + "ms");
			}
		}
		if (log.isDebugEnabled()) {
			log.debug("Executed Phase " + event.getPhaseId());
		}
	}

	public void beforePhase(PhaseEvent event) {

		if (event.getPhaseId() == PhaseId.RESTORE_VIEW) {
			startTime = System.nanoTime();
		}
	}

	public PhaseId getPhaseId() {
		return PhaseId.ANY_PHASE;
	}

}

To use this, simply add the class to your project and insert a new phase listener in the faces-config.xml file.

  <lifecycle>
    <phase-listener>package.name.LogPhaseListener</phase-listener>
  </lifecycle>

While it may not be totally accurate, it at least gives you an idea of the scale of the duration of a request (i.e. 68ms versus 394ms). I’ve used this fairly effectively in a few projects to cut out some bottlenecks as well as comparing and contrasting different JSF frameworks.