JSF frameworks: Shale and Seam

Enhanced techniques for building JavaServer Faces applications

JavaServer Faces (JSF) brings a new paradigm to developing Web-based applications in Java. Released a few years ago, but now slated to become part of Java Enterprise Edition 5 (Java EE is Sun's new name for J2EE), JSF will gradually supplant the old manner of structuring Java Web tier applications in JavaServer Pages (JSP) and servlets. JSF, whether by standardizing multi-device renderable UI components for delivering specific device markup, or allowing interfaces to be defined by prebuilt parts—widgets, buttons, menus, among other things—or tightening the link between client-side events and server application logic, is an embodiment of lessons learned from Java Web development throughout the years.

However, its out-of-the-box state is not without its faults. In this article, I illustrate how a particular set of frameworks—specifically, Shale from the Apache Software Foundation and Seam from JBoss—has already stepped up to fill in the gaps of this up-and-coming Java technology. With that said, you should realize that JSF represents an elaborate technology in and of itself, so if you are unfamiliar with its core concepts, you are advised to check out the links in Resources to get up to speed on the terminology used in our exploration, as we will jump right into the deep end of JSF.

JSF in isolation

No technology evolves in a vacuum, and Java is testament to this. More than 300 working groups are trying to incorporate the latest and most innovative approaches to using Java for particular software development tasks, and JSF composes just one of these many groups. The latest milestone release for JSF represented by the 1.2 version has two reference implementations: the Apache Software Foundation's MyFaces and Sun Microsystems' de facto reference implementation.

While JSF's working group tries to pack as much functionality as possible in each release, three primary reasons hinder the inclusion of interesting and powerful features and give way to frameworks such as Shale and Seam:

  • Consensus: Most Java working groups are composed of various industry players. While this guarantees compatibility among many different products, it also slows the adoption process for features that might be considered unique to particular vendors' needs.
  • Cross functionalities: Java specifications, more often than not, need to play well together with other Java specifications; this leads to open-ended scenarios that in turn require ad hoc bridging techniques to tailor an adequate solution.
  • Scope creep: Like any technology, release points have to be defined, where unfortunately the next big thing has to wait until the next release cycle.

Given these aforementioned facts, let's look at what can actually be done with JSF in its 1.2 release. As we move on, we will modify this application, addressing what features can make JSF development more efficient through particular offerings in Seam and Shale.

Our application allows users to reserve flights by providing their email addresses along with departure dates and destination cities—you can observe a snapshot of this application in the figure below. Things are kept relatively simple, but this initial iteration does try to pack a few standard features so even uninitiated JSF users can grasp the capabilities behind the technology. Listing 1 shows the JSF markup page that generates the output presented in the illustration.

Reservation form composed by JSF. Click on thumbnail to view full-sized image.

Listing 1. JSF markup page for reservation form

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %> <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %> <%@ taglib uri="http://myfaces.apache.org/tomahawk" prefix="t"%>

<html> <head> <title>Metro Systems </title> <link href="css/style.css" rel="stylesheet" type="text/css"> </head> <body>

<div id="container">

<f:loadBundle basename="com.webforefront.resource.booking_messages" var="booking_messages"/>

<f:view> <h3> <h:outputText value="


"/> </h3> <h:form> <table align="center" cellpadding="5" cellspacing="5"> <tr> <td>Email</td> <td><h:inputText id="email" value="


"/> </td> </tr> <tr> <td><h:outputText id="departure" value="


"/></td> <td>

<t:inputCalendar monthYearRowClass="yearMonthHeader" weekRowClass="weekHeader" currentDayCellClass="currentDayCell" value="


" renderAsPopup="true" popupTodayString="#{booking_messages['popup_today_string']}" popupWeekString="#{booking_messages['popup_week_string']}"/> </td> </tr> <tr> <td><h:outputText value="#{booking_messages['city']}"/> </td> <td> <h:selectOneMenu value="#{flight.city}" required="true">

<f:selectItem itemLabel="Los Angeles" itemValue="Los Angeles"/> <f:selectItem itemLabel="Madrid" itemValue="Madrid"/> <f:selectItem itemLabel="Mexico City" itemValue="Mexico City"/> <f:selectItem itemLabel="New York" itemValue="New York"/> <f:selectItem itemLabel="Paris" itemValue="Paris"/> </h:selectOneMenu></td> </tr> </table>

<h:commandButton type="submit" value="#{booking_messages['reserve']}" action="#{flight.reserve}"/> <h:messages/> </h:form>

</f:view> </div> </body> </html>

Most of the markup in this compact listing belongs to three JSF tag libraries: Core, HTML, and Tomahawk. While going into tag specifics would go beyond this article's scope, three details are worth mentioning:

  1. The <f:loadBundle> declaration gives internationalization (i18n) capabilities to our application. The basename attribute is used to specify the namespace of the language bundles, while var is the reference name used for extracting resource values. Scattered throughout the page you will notice attribute declarations in the form value="#{booking_messages['*']}" that represent i18n values, which, depending on a user's browser locale, will be substituted with his/her corresponding language values. (See the application's source code (downloadable from Resources) if you are unfamiliar with i18n bundle deployment.)
  2. The single markup line <t:inputCalendar> generates our entire pop-up calendar—that's an individual line that creates extensive HTML and JavaScript logic, which is JSF's touted component focus. The actual code is tucked away as a JSF component in the Tomahawk library provided in the Apache MyFaces JSF implementation.
  3. Notice the attributes with markup in the form value="#{flight.*}". The name of the backing bean is flight, and the second value represents the field name defined in the bean. In our case, the field names are email, departure, and city. Although flight.reserve is part of the backing bean, it's not a field per se, but we will get to that later.

This markup is only part of our application, the remaining elements, which are the backing bean and deployment descriptors, will be made much simpler or abbreviated as we move along and use either Shale or Seam. If you want to look at the standalone JSF application, see Resources to download the sample code. Now we will move forward with our first look at Shale.


Shale actually emerged from an earlier Java framework devoted to dealing with JSP pages and servlets: Struts. This last framework was among the pioneers in Java Web development and provided much of the building blocks for Model 2 designs—a variation of the MVC (Model View Controller) paradigm. Though Struts managed to garner a wide user base, its roots tied it down to the underlying architecture of JSP and servlets, which of course vastly differ from JSF. So to this end, Shale is a fresh incarnation of Struts written to leverage JSF's component-oriented architecture.

Framework compatibility: Application server and JSF implementation
Though standard JSF applications should function equally across any JSF implementation and any Java application server or Web container on the market (see Resources for application servers and JSF implementations), a higher-level framework like Seam or Shale is inevitably pegged or more thoroughly designed to work with a particular application server or JSF implementation. For example, Shale works best with Jakarta Tomcat, and Seam works best with JBoss Application Server—both using the MyFaces implementation developed by Apache. Regardless, you can still use these JSF frameworks in another server environment, though you may experience a little trouble when entering the deployment phase.

If you have previously worked with Struts, then some of Shale's features will surely look familiar. The difference is that you can now take advantage of them in a completely JSF-centric manner.

Among Shale's offerings are the following:

  • View controller, allowing extra services to be accessible from JSF backing beans
  • Dialog manager, for defining navigation rules needed to manage transitions between views
  • Integration facilities in areas like Java Naming and Directory Interface, Spring, and Tiles, among others

There is nothing like seeing for believing, so let's get down to modifying our existing JSF applications and use two of Shale's many functionalities.

JSF annotations and validation with Shale

Annotations are metadata placed within source code, which can later be used for configuration or execution purposes. While the approach is not new to programming or Java, this capability was previously only achievable using frameworks like XDoclet. But with the emergence of J2SE 5.0, annotations are ushering in a standard that will form part of the core Java language. JSF's most recent release grew in total isolation of the annotation functionalities provided in J2SE 5.0, but with Shale, you can leverage annotations for developing JSF solutions.

You need J2SE 5.0 for annotation support
To execute a JSF application using annotations in either Shale or Seam, you must upgrade your JDK to version 5.0.

Data validation is another aspect that, although given consideration in JSF—especially compared to JSP and servlets, which had none—can still be enhanced. Shale builds on its predecessor, Struts, and employs the same form-validating techniques using Apache Commons to lift the burden of writing server-side validation scaffolding code.

The bulk of our reworked JSF application avoids the use of JSF's deployment descriptor and instead uses annotations directly in the application's source code. This will grant us the benefits of having the same entry point for both configuring and developing JSF components, converters, renderers, and validators. We will also integrate Shale's validation library into our JSF markup to guarantee data integrity.

Listing 2. JSF backing bean with annotations for Shale Framework

1 2 3 Page 1
Page 1 of 3