What’s New in JSF 2?

With so many sources of information available on JSF 2, why bother with another overview? After all, this ground has already been covered quite extensively:

One problem I have been facing is deciding where to point my Oracle colleagues who are interested in a quick introduction to the JSF 2.0 feature set. The spec contains all of the information, but that’s some pretty heavy reading. The blogs do a phenomenal job of covering specific features but do not provide a big picture overview. The Webinar provides the big picture overview, but some folks might prefer reading over listening/watching. The slides also provide an overview, but I wanted something with more prose than bullets.

So, on the theory that more is good, and since I could not find quite what I was looking for, I decided to spend some time writing up my own take on the new JSF 2.0 feature set. Of course, I borrowed from all of the above sources while working on this, so many thanks to my JSF colleagues for making my job easier!

Note that I do not attempt to cover these features in extreme detail. This is just an overview. However, each section includes links to more detailed information where available, so please click through if you do not find the level of detail that you need here.


View Declaration Language and Facelets

Not to knock JSP, but even JSP champions must admit: JSP as the primary view technology for JSF has not been a walk in the park. The problems have been discussed for years, dating back to the now classic Improving JSF by Dumping JSP, published back in 2004 just months after the JSF 1.0 spec was released. As of JSF 1.2/JSP 2.1, several of the key issues have been addressed. However, the JSF/JSP combination certainly has room for improvement.

The JSF community has not been sitting still. Several JSF-optimized alternatives to JSP have emerged, including Apache Shale’s Clay (now retired), JSFTemplating and Facelets. However, the lack of a standard solution remains a sore point for JSF users. JSF 2.0 recognizes the need for a standard alternative to JSP and addresses this by taking two steps.

First, JSF 2 provides a generic foundation for integrating view declaration languages into the JSF runtime environment. The ViewDeclarationLanguage API defines the contract through the JSF runtime interacts view declaration language implementations in order to complete tasks such as building up the component tree. This contract allows framework authors to define their own view declaration languages and integrate these with JSF in a standard way.

Second, JSF introduces the first standard non-JSP view declaration language: Facelets! JSF 2.0 includes a re-purposed version of the Facelets 1.x API/implementation. This 2.0 version of Facelets should be very familiar to anyone who has been using Facelets 1.x. Most of the 1.x APIs are present, though there has been some tweaking/repackaging as part of the standardization process.

The inclusion of Facelets as a standard view declaration language should ease any concerns that development teams may have about embracing this technology.

While Facelets is a new focus for the JSF specification, JSP support is still available for those users who are not ready to make the jump to a new view definition technology. Note, however, that the JSP side of the JSF specification is basically standing still. None of the new features that involve new tags (composite components, system events, Ajax, etc…) are exposed through JSP.


Composite Components

Let’s take a quick look at how to implement a custom component in JSF 1.x: Just implement your UIComponent subclass, and… done! Oh,wait… you might want to move your markup rendering code into a Renderer. Oh, and don’t forget to register your component and renderer in a faces-config.xml file. Er… then you just need to implement your JSP tag. Oh, and don’t forget that tld!

Okay, so JSF custom component development has always been a chore. The problems have long been known and are well documented.

JSF 2 greatly simplifies custom component development with the introduction of the “composite component” feature. This feature allows a custom component to be implemented with a single file – no Java code required.

Let’s take a look at the obligatory “Hello, World!” example, starting with a composite component that renders the salutation:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
<html xmlns="http://www.w3.org/1999/xhtml"
<title>My First Composite Component</title>

    <composite:attribute name="who"/>

    <h:outputText value="Hello, #{cc.attrs.who}!"/>


The composite component is defined via an XML file containing XHTML contents plus elements from the “http://java.sun.com/jsf/composite&#8221; namespace. The <composite:interface> element contains metadata that describes the characteristics of component, such as supported attributes, facets and attach points for event listeners. The <composite:implementation> element contains the markup that is substituted for the composite component when it is referenced by a consuming page.

To make the composite component available for use, we simply drop this file into a “resources” directory (more on resource loading later). The tag name for the composite component is derived from the file name. The tag namespace is based on the location of the composite component within the resources directory.

If we dump the above code in a “Hello.xhtml” file inside of a “resources/greet” directory, we end up with the following:

We can then reference our new component as follows:

<html xmlns="http://www.w3.org/1999/xhtml"

  <!-- Snip -->

  <greet:hello who="World"/>


That’s quite a simplification from earlier days of writing UIComponent subclasses, renderers, tags, faces-config.xml entries and tlds!

The composite component architecture is much more sophisticated than demonstrated with this minimal sample. Support for all of the usual component-centric functionality is provided, including inserting facets, adding children, attaching listeners, validators, converters, etc… See the links below for more extensive coverage of JSF 2 composite components.



Here we are, 2009, four years since the term Ajax was coined. Hasn’t the JSF/Ajax integration problem been solved yet?

Well, actually, yes, it has. If the JSF AJAX Component Library Feature Matrix is any indication, this problem has been solved many times!

The availability of so many JSF/Ajax frameworks is a good indication that JSF provides a strong foundation for Ajax. So, does that mean that we are done? What’s left for the JSF spec to do?

Well, two things actually:

  1. Compatibility. While it is impressive that so many JSF/Ajax solutions are available, the subtle differences between these solutions lead to cross-framework compatibility problems.
  2. Native Support. Isn’t it time that JSF users have access to Ajax functionality without requiring a 3rd party framework?

JSF 2 attempts to address both of these issues by providing various new Ajax-related APIs and infrastructure. Let’s take a look at these by walking through the lifecycle of a typical Ajax request.

Ajax Request Lifecycle

Starting on the client, JSF 2 exposes a new JavaScript API, jsf.ajax.request(), that issues an Ajax request back to the current view. This method collects any data that needs to be included with the request, prepares the request payload, registers a response handling callback and then posts the request back into the Faces lifecycle.

Once the request enters the Faces lifecycle, the state of the Ajax request is captured via the PartialViewContext. This object provides access to information such as which components are targeted for processing/rendering. The PartialViewContext’s processPartial() method uses this information to perform partial subtree processing/rendering.

When the rendered response is sent back to the client, the callback previously provided by jsf.ajax.request() is invoked. This callback automatically updates the client-side DOM to reflect the newly rendered markup.

In order to encourage compatibility across JSF components/frameworks, the request and response payloads have also been standardized.


The jsf.ajax.request() JavaScript API is a primitive that is primarily targeted for use by frameworks as well as by the JSF implementation itself. JSF 2 also includes a declarative approach that is intended to be more convenient for page authors. This approach leverages the new <f:ajax> tag.

Instead of manually coding the JavaScript for the Ajax request call:

  <h:commandButton onclick="jsf.ajax.request(this,event,{render:'foo'});return false;"/>

Page authors can declaratively specify the same behavior:

    <f:ajax render="foo"/>

The presence of the <f:ajax> tag enhances the markup of the associated component to include a script that triggers the Ajax request. This allows Ajax requests to be issued without requiring the page author to write any JavaScript code.


State Saving

JSF state saving has long been a sore point, both for application developers as well as component developers. The main problem for application developers is that the size of the saved state can be large. This makes client-side state saving impractical and leads to session state bloat. For component developers, the issue is that implementing saveState and restoreState methods is tedious and error prone.

JSF 2.0 addresses these issues with the introduction of a new “partial” state saving mechanism. This solution was inspired by a proposal that Adam Winer made (and implemented in Apache Trinidad) over 3 years ago. The key concept is that saving the entire state of the component tree is redundant, since the component tree can always be restored to its initial state by re-executing the view (ie. by re-executing Facelet handlers to re-create the component tree).

If we use the view definition to restore the component tree to its initial state, then the only state that needs to be saved is state that has been modified since the view was initially created. And since in most cases the number of components that are modified after component tree creation is small, the size of this delta state is typically much smaller than the full component tree state.

A requirement for the delta/partial state saving approach is that component implementations must know when their initial state has been fully configured. JSF 2 introduces the PartialStateHolder contract to help with this requirement. The PartialStateHolder’s markInitialState() method is called to notify the implementing component that its intial state has been established. Only modifications that occur after this notification need to be saved.

A second API has been introduced to help component implementations manage their state: StateHelper. The StateHelper provides storage for component state (such as attributes, listeners, etc…) and relieves the component author from having to provide custom saveState and restoreState implementations.

As a result of these new APIs, JSF 2 state saving is both more efficient and easier to use!

If the PartialStateHolder/StateHelper APIs seem vaguely familiar to you, you just might be thinking of Apache Trinidad’s FacesBean.


System Events

JSF 1.x includes two event delivery mechanisms. FacesEvents are delivered to FacesListeners in response to user interaction, such as editing an input component, or activating a command component. PhaseEvents are delivered to PhaseListeners at the beginning and end of each phase in the Faces lifecycle. These solutions do not include notification of other interesting events that occur during the processing of a Faces request.

JSF 2’s system events provide the ability to deliver SystemEvents to SystemEventListeners at arbitrary points during the request processing lifecycle. System events fall into two categories: global system events and component system events.

Global system events are delivered in response to application-wide activities, for example Application initialization/destruction. Listeners for these events are registered via a call to Application.subscribeToEvent().

Component system events are specific to individual component instances. For example, a component system event is delivered each time a component has been added to the view, or rendered, or validated. Component system event listeners are typically registered via a call to UIComponent.subscribeToEvent(). However, component system events also bubble up to the Application, where they are re-delivered to Application-level listeners. This allows global monitoring of component-related events.

Both global and component system events are fired by calling Application.publishEvent().

In order to simplify listener registration for component-specific events, JSF also provides a declarative listener registration solution via the <f:event> tag. To register a listener declaratively, simply place the <f:event> tag inside of the target component. For example:

    <f:event type="preValidate" listener="#{bean.doSomePreValidation}"/>

This registers the method located at #{bean.doSomePreValidation} as a pre-validation listener for the parent inputText component.

By providing notification of all sorts of activities that previously went undetected, system events open up many possibilities for page authors, component authors, framework authors and also for the JSF implementation itself!



Implicit Navigation

In JSF 1.x, even the most trivial navigation cases required an entry in faces-config.xml. For example, when navigating from page1 to page2 in response to a “success” outcome on a command component in page1 required the following XML boilerplate code:


Fun stuff, right?

JSF 2.0 introduces a simplification that reduces navigation-related grunge code: implicit navigation. If no matching navigation case is found after checking all available rules, the navigation handler checks to see whether the action outcome corresponds to a view id. If a view matching the action outcome is found, an implicit navigation to the matching view occurs.

The end result: smaller faces-config.xml files. Oh, and happier JSF users.

Conditional Navigation

Another enhancement to the navigation subsystem is the addition of conditional navigation cases. The conditional navigation feature allows navigation cases to specify a pre-condition that must be met in order for the navigation case to be accepted. The pre-condition is specified as an EL expression using the new <if> configuration element:


      <!-- Only accept this case if the following condition is true -->


One of the motivations behind this feature is to allow pre-conditions to be implemented in a loosely coupled, navigation-agnostic way. Instead of requiring a managed bean or business layer object return a navigation-centric outcome value, we can now use EL to interact with arbitrary properties/methods on these objects, freeing these objects from awareness of the JSF navigation system.

Preemptive Navigation

The JSF 1.x navigation system is a black box. The only entry point, NavigationHandler.handleNavigation(), simply evaluates the navigation rules and causes a navigation to occur, without giving any insight into how the navigation target is determined.

JSF 2.0 provides more transparent view of the navigation system. The new ConfigurableNavigationHandler API provides access to metadata describing the available navigation rules/cases. In particular, the getNavigationCase method allows clients to ask the ConfigurableNavigationHandler to determine which navigation case matches a particular outcome and from action. With this new contract, it is possible to “preemptively” evaluate navigation rules and retrieve the resulting target view id and URL.

Why is this interesting? Well, before JSF 2.0, navigation rules were explicitly the domain of POST requests. Previously, the only time that navigation rules came into play was during the invoke application phase while handling a POST. By making the navigation rules available outside of invoke application, we open up the possibility of leveraging this information at other points in the lifecycle, for example, during render response.

As we’ll see in the next topic, this has some interesting consequences relating to better support for GET-based navigation and bookmarkability, an area that has received much interest in recent years.


GET Support

It’s not so much that JSF 1.x does not provide any support for GET request handling… after all, there are some low-level primitives (like PhaseListeners) available. However, there is no denying that GET requests are a second-class citizen in earlier versions of the JSF specification. JSF 2.0 introduces several features that tackle this shortcoming.

View Parameters

The JSF 1.x specification goes to great lengths to provide a robust lifecycle for processing of values arriving from the client via Http requests. Values are pulled from the request, converted from strings to the proper target type, validated against application-specified constraints and finally, pushed into the model. Very powerful.

Of course, there is one caveat: all of this processing only applies to values arriving on POST requests. If the same value arrives via a GET request, well… tough luck! Or, well, maybe write a PhaseListener to manually process the request. Oh, and good luck reusing your converter/validator implementations to process those values!

JSF 2 brings some sanity to this situation with the introduction of “view parameters”, inspired by Seam’s page parameters. View parameters provide a simple, declarative way to map incoming request parameter values to any EL-reachable location. These mappings are specified using the new <f:viewParam> component, which lives in the (also new) <f:metadata> section of the view, eg:

    <f:viewParam name="foo" value="#{bean.foo}"/>

The above sample specifies that the value of the request parameter with the name “foo” will automatically be picked off of the request and pushed into the property at #{bean.foo}. So if we receive a GET request as follows:


The value #{bean.foo} property will be set to “bar” when JSF starts processing the request. No more need to manually code this sort of mapping in a PhaseListener. Yay!

But wait, there is more… The <f:viewParam> component happens to be an EditableValueHolder, which means that view parameters can participate in conversion/validation. You can attach any converter/validator to an <f:viewParam> component , just as you would with, say, <f:inputText>. No more need to write custom conversion/validation logic specifically for GET processing.

PreRenderView Event

View parameters bring to GET requests much of the JSF request processing lifecycle that was formerly reserved for POSTs: request parameter decoding, type conversion, validation and model updates. But view parameters stop short of one last important step: invoking application-defined listeners. For this, system events come to the rescue.

JSF 2 includes a PreRenderViewEvent that is fired after view parameters have finished processing, but before the view is rendered. The pre-render view listener can be registered using the <f:event> tag, eg:

    <f:viewParam name="foo" value="#{bean.foo}"/>
    <f:event type="preRenderView" listener="#{bean.doSomething}"/>

This listener might be used to load data or set up context that is required prior to rendering. In addition, the listener may choose to programmatically navigate away from the requested view in the event that some pre-condition is not met (eg. the user does not have access to the requested page).

With the addition of view parameters and the pre-render view event, the GET request processing lifecycle is finally on par with the rich lifecycle provided for POSTs.


Now that we have the ability to respond to GET requests more effectively, what about the flip side? How do we issue these GET requests in the first place? Looking at the JSF 1.x components, <h:commandButton> and <h:commandLink> do not fit the bill as these components are form/POST-centric. <h:outputLink> works, but has the drawback that it requires manual construction of the destination URL.

JSF 2 includes two new components that simplify GET-centric navigation: <h:link> and <h:button>. With these components, the page author no longer needs to hand code the destination URL. These components leverage the JSF navigation system to determine the appropriate destination. Instead of explicitly specifying the URL, users specify the desired logical outcome, eg:

  <h:link outcome="success"/>

Preemptive navigation is used to translate this logical outcome into a physical destination. At render time, the navigation system is consulted to map the outcome to a target view id, which is then transparently converted into the destination URL. This frees the page author from having to worry about manual URL construction.

Note that the URL construction process is not solely based on the target view id. The <h:link> and <h:button> components also integrate nicely with view parameters. By specifying the includeViewParams attribute, eg:

  <h:link outcome="success" includeViewParams="true">

The view parameters specified by the destination view are taken into account when building up the URL – ie. an inverse mapping of the view parameters is applied. Each view parameter value is extracted from the location specified by its EL expression, converted to a string, and added to the query string under the view parameter’s name.

This provides a simple yet powerful mechanism inserting required parameters into the query string. It also provides a nice technique for transferring request-scope data across requests.

In addition, page authors may manually insert query parameters using the <f:param> tag, eg:

  <h:link outcome="success">
    <f:param name="foo" value="bar"/>

And of course, the key benefit of this solution: the resulting URLs are bookmarkable!



View Scope

View scope is one of two new scopes introduced in JSF 2 that fall into the category of “longer than request, shorter than session” scopes. As the name implies, state that is placed into view scope is preserved until the user finishes interaction with the current view. If you have ever had the joy of trying to figure out why your command component isn’t firing after binding the rendered attribute to a request-scoped managed bean, view scope may just be the answer to your problems.

View scope state can be accessed programmatically via UIViewRoot.getViewMap(). EL access is available via the #{viewScope} implicit object.

Flash Scope

JSF 2 borrows a concept from Rails with the introduction of the new flash scope. Flash scope provides a short-lived conversation. State that is placed into flash scope is propagated across a single view transition, including surviving redirects, and is cleaned up before moving on to yet another view. If you have been resorting to session scope to store state that needs to survive a redirect, flash scope might just be for you.

Flash scope state can be accessed programmatically via the ExternalContext.getFlash() API. EL access is available via the #{flash} implicit object.

Custom Scopes

JSF 2 also provides a small enhancement to the managed bean system to allow faces-config.xml authors to place managed beans into custom scopes. The trick is that custom scopes are specified via an EL expression rather than a keyword, eg:


The EL expression identifies the location of a map that holds the properties for the scope. When it is time to instantiate a custom-scoped managed bean, the managed bean system automatically pushes the new instance into the map under the specified name.



Managed Bean Annotations

JSF 2 provides a long awaited usability improvement with the introduction of annotation-based configuration. The goal of these annotations is to reduce the size and complexity of faces-config.xml files, which have a tendency to get quickly out of hand. The first set of annotations allows developers to configure managed beans. The old style XML configuration:


Can now be replaced with annotations on the bean class:

public class Foo {

The name for the managed bean is automatically derived from the name of the annotated class. In the above example, the presence of @ManagedBean annotation on the Foo class makes a managed bean with the name “foo” available. Alternatively, the @ManagedBean annotation also allows a name to be specified explicitly.

Annotations are also available for the other scopes, as well as for managed properties.

Note: An effort is underway to unify these bean/scope annotations across specifications (eg. JSF, JCDI) for Java EE 6. In the meantime, the JSF 2 managed bean annotations are considered an optional part of the JSF 2 specification. Mojarra and MyFaces already provide implementations of these optional annotations.

Component Annotations

As part of the effort to prune down XML configuration bloat, JSF 2 also includes annotations targeted at authors of custom components (and associated objects). These annotations include:

  • @FacesComponent
  • @FacesRenderer
  • @FacesConverter
  • @FacesValidator
  • @FacesBehavior

Of course, the good old faces-config.xml elements are still present for those who prefer to go that route.

Faces-config.xml Ordering

A long-standing problem with faces-config.xml loading is that the order in which these files are loaded is unspecified. For the most part (eg. for managed bean or navigation configuration) the order is not significant. However, there are certain cases, such as decorating Application-level objects (eg. ViewHandlers), where the order may matter.

During the JSF 1.2 timeframe, both MyFaces and the JSF RI adopted a convention whereby faces-config.xml files are loaded based on an order derived from the containing jar file’s name. However, this was just a temporary implementation-level solution that was put in place until the issue could be addressed by the specification.

JSF 2 solves this problem by allowing faces-config.xml files to provide ordering-related hints. Each faces-config.xml file may now declare a name (via a new <name> element) that can be referenced by other faces-config.xml files for ordering purposes. A new <ordering> element and sub-elements allow relative ordering requirements to be specified.

This addition to the spec provides a much cleaner/safer way for the various frameworks/component sets to play together in the JSF ecosystem. No more jar file name hacking!

Project Stage

Project stage is a new configuration option that allows the application developer/deployer to specify a hint to the JSF implementation regarding the role of the current deployment. Valid values include:

  • Development
  • Production
  • SystemTest
  • UnitTest

This hint allows the JSF implementation to optimize its behavior for the current stage. For example, the JSF implementation might provide more verbose development-time diagnostics than would be practical for a production environment.

For a more specific example, check out the Mojarra team’s recent use of project stage to provide automatic compression of JSF’s own JavaScript library.

The project stage can be set either as a context parameter (“javax.faces.PROJECT_STAGE”) or via JNDI (“java:comp/env/jsf/ProjectStage”).

And, yes, my good friend and colleague Matthias Wessendorf would also like to see the project stage exposed as a system property. 🙂



The original JSF 1.0 specification introduced the concept of “attached objects” – ie. objects that are not UIComponents, but are attached to UIComponents in order to influence some aspect of the component’s behavior. This technique is used for conversion and validation by value holding components, eg:

  <h:inputText value="#{foo.value}">
    <f:convertNumber integerOnly="true"/>

JSF 2 adds a new class of attached object: the ClientBehavior. Whereas converters/validators focus on value processing, client behaviors assist in enhancing a component’s client-side functionality. Before client behaviors, page authors were forced to resort to hand-coding scripts and manually wiring these scripts up via event handling attributes, eg:

  <h:commandLink onclick="return confirm('Really???')"/>

Client behaviors allow such scripts to be packaged up into reusable bundles that can be attached to components declaratively, eg:

    <foo:confirm message="Really???"/>

This declarative approach is made possible by the introduction of two new contracts (along with various supporting APIs). The ClientBehavior contract specifies how client behavior implementations provide access to scripts and more generally how these objects participate in the component lifecycle. The ClientBehaviorHolder contract specifies how client behaviors are attached to components, similar to how EditableValueHolder specifies how converters and validators are attached.

In addition to defining these new contracts, JSF 2 also includes one concrete ClientBehavior implementation: the AjaxBehavior. The declarative form of this client behavior should be familiar from our earlier discussion on Ajax:


Although the JSF specification only defines a single concrete client behavior, the client behavior architecture is designed for extensibility. Expect to see plenty of third party client behavior implementations popping up!



Bean Validation

The Bean Validation JSR (JSR-303) defines a generic, tier-independent mechanism for specifying data validation constraints. The specification includes several standard constraint annotations (eg. @NotNull, @Size, @Min, @Max, etc…) and also allows custom constraints to be defined.

JSF 2 provides built-in integration with JSR-303 constraints. In environments where a bean validation implementation is present, JSF automatically validates constraints for beans that are referenced by UIInput values.

In addition, <f:validateBean> may be used to fine tune bean validation behavior. For example, the validationGroups attribute may be used to manually specify which validation groups should be taken into account when validating a particular component:

  <h:inputText value="#{bean.foo}">
    <f:validateBean validationGroups="com.foo.validation.groups.Billable"/>

When validation constraints fail, any associated error messages are automatically translated into FacesMessages by the JSF implementation, thus communicating the failures to the end user without placing any burden on the application developer.

Empty Field Validation

In previous JSF releases, Validators were not applied to EditableValueHolder components with null/empty submitted values. Unfortunately, this behavior limits the utility of constraints that actually check null/empty values, such as the JSR 303 @NotNull constraint. In order to support @NotNull and other similar constraints, JSF 2 changes the behavior of null/empty value validation. As of JSF 2, when a JSR-303 implementation is present, null/empty values are validated.

Since this may cause problems for legacy Validator implementations that do not expect to see null/empty values, the javax.faces.VALIDATE_EMPTY_FIELDS context parameter can be used to disable this behavior.

New Validators

In addition to <f:validateBean>, JSF 2 includes two other new validators:

  1. <f:validateRequired> provides required field validation.
  2. <f:validateRegexp> provides regular expression-based validation


Error Handling

JSF users who are new to Facelets will appreciate the more informative Facelets error page that provides information such as: line numbers! (And no, not just stack trace line numbers, but actual line numbers within the Facelets file.)

Of course, error pages are only useful in cases where the triggering exceptions are allowed to propagate up to the error handling layer and not pre-maturely consumed. The JSF 2 specification helps in this area with the introduction of the new ExceptionHandler API. JSF implementations are now required to allow all “unexpected” exceptions to propagate out of the current lifecycle phase so that they can be handled globally by an ExceptionHandler instance.

This change should reduce/eliminate those mysterious, hard to debug “swallowed” exceptions, as the ExceptionHandler now acts as a central clearing house for exceptions. Another advantage of this centralization is that it allows users/frameworks to devise more sophisticated error handling strategies.

Resource Loading

If you spend time implementing custom JSF components of any complexity, eventually you are going to run into the question: what do I do with my component’s images (or JavaScript libraries, or style sheets)? Just about every JSF component framework has run into this problem and, in the absence of a standard solution, has solved this problem in its own proprietary way.

JSF 2 provides a standard solution to this problem with the introduction of the ResourceHandler API. The ResourceHandler is responsible for serving up resources (images, JavaScript files, style sheets, etc…) from well-known locations on the class path. Resource requests are routed through the FacesServlet, which passes these request onto the ResourceHandler for processing. This solution allows components and their resource dependencies to be bundled in the same jar file with no need for a bonus servlet, servlet filter or phase listener to serve up these artifacts.

JSF 2 also provides several new features in order to facilitate insertion of resource references. Authors of custom Java components can annotate their UIComponent subclasses with the @ResourceDependency annotation to identify any resources that need to be pulled in when the component is used. Composite component authors can use the new <h:outputScript> and <h:outputStylesheet> to pull in scripts and style sheets. The #{resource} implicit object provides direct EL access to resource URLs.

The @ResourceDependency annotation and the <h:outputScript>/<h:outputStylesheet> components take advantage of another new feature: resource relocation. Resource relocation gives the component/page author control over where resource references are inserted into the rendered markup. For example, resource references may be inserted into the document head or at the end of the body. In addition to providing flexibility in where resources are inserted, a beneficial side effect of resource relocation is that duplicate resource references are automatically pruned out.

Note that in order to support resource relocation, JSF 2 introduces two other new components: <h:head> and <h:body> These components render the HTML head/body markup and also provide a target for relocatable resources.


Tree Visiting

JSF 1.2 included the most useful addition of the UIComponent.invokeOnComponent() API. This provided the ability to invoke a callback on a single component instance in context. This functionality is particularly handy for any case where a single component (or subtree) needs to be targeted. (Think Ajax.)

While invokeOnComponent() is an excellent solution for the single component case, it is not particularly optimized for the multiple component case. If you need to target two components (eg. need to render two separate subtrees while processing an Ajax request), invokeOnComponent() will work, but requires two tree traversals in order to locate the two components. What happens if you need to render five separate subtrees? Or, even worse, what if you want to visit every component in context? Unfortunately invokeOnComponent() is not the answer.

JSF 2.0 solves the multi-component visiting case by introducing a sibling API to invokeOnComponent(): UIComponent.visitTree(). Both of these APIs traverse the component tree and invoke a callback on a subset of components. While invokeOnComponent() is designed to visit a single component, visitTree() may visit multiple components – and possibly all components – during its traversal. The set of components to visit is specified via a VisitContext that is passed into the visitTree() call.

While tree visiting is currently used under the covers by JSF implementations for features such as Ajax and state saving, the hope is that JSF frameworks/users will find other use cases where this new API proves helpful. If you currently have any case where you are calling invokeOnComponent() repeatedly (or are calling findComponent() when you should be calling invokeOnComponent()), be sure to check out the new tree visitor API!



When I starting thinking about writing this article, I was hoping to provide a comprehensive overview of the entire JSF 2 feature set. As I got further into this undertaking, I realized that covering every single new feature/API in a single blog entry might be a bit, well… unwieldy. As such I decided to trim back my plans, but just slightly. There are a small number of minor API additions that I have not discussed here. Perhaps I’ll add a new section on these minor APIs at some point. For the moment, I am hoping that the information provided here is sufficiently complete to meet my original goal of providing a good introduction to the JSF 2 feature set.

If I have missed some feature/API that you think deserves discussion here, please leave a comment. Or if you know of other good sources of information, please leave a link. I am planning to update this blog from time to time with links to new blogs/articles as they become available, perhaps even to some that I write myself. 🙂

77 Responses to “What’s New in JSF 2?”

  1. Learning JSF 2 | Maxa Blog Says:

    […] you are starting to learn JSF 2, this post by Andy Schwartz is an excellent place to start. It summarises and gives an excellent overview of […]

  2. Ed Burns Says:

    Great summary. The more the merrier.

  3. Brian Albers Says:

    Nice writeup, Andy!

  4. What’s New in JSF 2? « Matt Cooper’s Weblog Says:

    […] https://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/ […]

  5. Two More (Very Good) JSF 2.0 Overviews | jeremy barnish | a lifestream Says:

    […] JSF 2.0 continues to show signs of good adoption in the enterprise world. From IBM’s DeveloperWorks, David Geary has posted JSF 2 Fu, Part 3. And, from the other side, Andy Schwartz, Oracle’s rep to JSR-314, has now published a very nice and complete What’s New in JSF 2?. […]

  6. Zamoyski Says:

    It looks much better than JSF 1.1.
    I’m looking forward to see how Spring-Webflow will integrate it, so JSF2 will be just view technology for great Spring-Webflow architecture (scopes, flows, states, Spring-managed beans, validators, …)

  7. Neil Griffin Says:

    Terrific writeup Andy!

  8. cagataycivici Says:

    Nice overview Andy, thanks for sharing.

  9. rogerk Says:

    Excellent summary of all the major features of JSF 2.0! Ever think about getting into authoring?

  10. Volnei Says:

    First of all, congratulations! This is a very usefull guide to start!!!
    Now, what about upload in JSF2? Why it’s not supported natively?

  11. What’s New in JSF 2? « Matthias Wessendorf’s Weblog Says:

    […] https://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/ […]

  12. Shawn Bertrand Says:

    Happy to see you’re in the design process for JSF 2.0. I see lots of stuff in here that originated from Oracle. Bravo!

  13. Dan Allen Says:

    Nice work Andy! This is a much needed consolidation of the new features. The concise summaries and the links to the related resources are both equally valuable.

  14. yross Says:

    Otimo post…

    Tinha visto alguns comentários e pequenos textos introdutorios de JSF 2.0, mas este esta muito completo.

    Muito bom!

  15. jistr Says:

    Hey that’s just perfect quality summary. Thanks a lot!

  16. JSF 2: What’s new? | public static final Says:

    […] What’s New in JSF 2? […]

  17. Agam Says:

    Excellent summary of all the major features of JSF 2.0 with precise explanation. I read it in a single go; thanks to your fantastic narration.

    Thanks a lot !!

  18. David Says:

    Thanks for the summary. Great job! I didn’t realize how much they were doing. I can’t wait until jsf 2 is out of beta and ready for production!

  19. Jeanne Says:

    Thanks for doing this, Andy. Your Oracle colleagues are appreciative, as always!

  20. TH Says:

    Nice post. You just bumped up by JSF2 awareness meter.

  21. Spec 2.0: JSF 2 Überblick | Information Centre Says:

    […] Andy Schwartz Blogeintrag Andy hat selbst eine Auflistung inklusive weitere Erklärung aufgeführt […]

  22. Hafid Says:

    Thanks for this listing and explanation!

  23. Lucas Jellema Says:

    This overview has been very helpful in authoring an article for the Dutch JUG’s Java Magazine. Thanks a lot for the great write up.

  24. AMIS Technology blog » Blog Archive » JavaServer Faces 2.0 - next generation JSF technology (specification) Says:

    […] What’s new in JSF 2.0 – by Andy Schwartz. […]

  25. Bill Harper Says:

    Thanks ! Awesome summary and overview.

  26. Dennis Says:

    Awesome, thank you!
    I like your way of mixing valuable information with ironic humour!

  27. Jobinesh Says:

    Great work Andy!

  28. Tim Schweers Says:

    Great work! I totally want to try out this stuff right now. Good bye hand-crafted GET integration and home-made view-scopes.

    Thanks a lot!

  29. lost in thought » JSF2 Linksammlung Says:

    […] Andy Schwartz’s Weblog – What’s New in JSF 2? (exzellente Übersicht!) […]

  30. Prakash Udupa Says:

    JSF 2 very nicely presented. Thanks Andy.

  31. San Says:

    nice post…really useful

  32. Jérôme Jadoulle Says:

    Thank you for the summary. I found it very useful to have a quick idea of what I can expect from the future of JSF.
    Great article!

  33. Lincoln Says:

    Awesome post, Andy! Just saw this.

  34. JSF 2.0 is already here. What’s new? « Technology drops Says:

    […] If you are starting within JSF 2.0 technology, you will probably find this article very interesting: https://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/ […]

  35. technicalbrainwave Says:

    Great article. Thanks for sharing!!

  36. Mojarra 2.0 publicado: implementación de JSF 2.0 Mojarra 2.0 publicado: implementación de JSF 2.0 « arrayexception.com - Tecnologia y Desarrollo Says:

    […] web a la altura de otras opciones en el mundo java. Entre las principales features, tomadas del blog de Andy Schwartz, […]

  37. userquin Says:

    Very very interesting summary. Congratulations Andy.

    JSF can be an alternative to JBoss Seam and Trinidad (and any other impl to solve “scope beans” such as scope and flash) in non J2EE environment, without third party impl (and no JTA or JCA dependencies, such as JBoss Micro Container), just mojarra.

    What about JSR-299? I think JBoss Seam is the reference (great work Seam team, the most evolution in J2EE), but this article mentions some others JSR/JCP but not integration with WebBeans.

    Thanks Andy.


  38. Blog do Marco Mendes » O complexo caminho da simplicidade do EJB 3.1 e o Java EE 6.0 Says:

    […] Felizmente temos observado este movimento em vários outros lugares da API Java. O JBOSS Seam inspirou a simplificação do JSF na nova especificação do JSF (JSF 2.0), conforme podemos observar neste artigo em anexo. […]

  39. Patrick Vitali Says:

    Very good job !!!

  40. Bindu Says:

    Nice post, Andy! Very easy to follow. Thanks.

  41. jik Says:

    Awesome stuff…thanks, Sir!

  42. Tim Büthe Says:

    Nice posting, great overview. Tahnks a lot!

  43. Carlos Lopez Says:

    VERY NICE POST THERE!!!! Pretty helpful.

    Thanks from Guatemala.

  44. Suneel Says:

    Awesome Andy! very very useful overview. I am trying to analyse the differences between JSF1.2 with JSF2 and what would be the adoption cost.

    This overview really helped.

    Do you have a link where i can get detailed description on each of these new features?

    Thanks Andy.

  45. Nik Says:

    *The* best summary of JSF 2 features (and the motivators to the changes) I’ve seen. This goes directly into my bookmarks.

  46. pavan Says:

    thanks a lot………. andy

  47. GurkanErdogdu Says:

    Very nice and neat introduction to JSF2 document. Thanks!

  48. RYGN Says:

    excellent article thank you !

  49. RichFaces with Hibernate Validator | Maxa Blog Says:

    […] release of Java EE 6, you can now use Bean Validation with JSF 2. If you are using JSF 1.2 (and that’s probably still most of you), you can use Seam to take […]

  50. jik Says:

    Thank you so much, Sir. This an awesome blog! I feel like I owe you…

  51. JSF 2 On The Road « Andy Schwartz’s Weblog Says:

    […] Our Complete Tour of the JavaServer Faces 2.0 Platform session (slides) was inspired by a webinar that JSF 2 co-spec lead Ed Burns gave back in May. Of course, with so many new features in JSF 2, a truly “complete” tour is a challenge. Jim and I hit the highlights, covering Facelets, composite components, Ajax, view parameters, system events, resource loading, partial state saving, etc… (If these topics aren’t ringing any bells for you, you might want to check out What’s New In JSF 2?.) […]

  52. Kenneth Mark Says:

    Great summary ! This way make my migration to JSF 2 much easier. Many thanks for the info.

  53. Carlos Ystranho Says:

    REALY, very, very good. I needed one like this, for begin.

  54. 2009 | Maxa Blog Says:

    […] you tried JSF 2 (and you should, it’s much better than JSF 1.2. Here is a great post by Andy Schwartz and here is my JSF 2 series), you will notice that core Ajax features in JSF 2 are very similar to […]

  55. Ashesh Says:

    Really a very good foundation read for JSF 2. I always enjoy reading your posts 🙂

  56. blog.smart-java.nl » Blog archief » JSF 2.0: Maximum flexibility with System Events Says:

    […] JSF 2.0 adds a lot of interesting features. Andy Schwartz provides an extensive overview on his blog. […]

  57. JSF 2.0 Says:

    […] about new features in JSF 2.0, but then I came across this excellent posting of July last year: What’s New in JSF 2? by Andy Schwartz of Oracle. I won’t rehash this and many other excellent postings on jsf […]

  58. An (almost) comprehensive list of Web Components « Jim Driscoll's Blog Says:

    […] a comment » In talking with Andy Schwartz before our recent talk together at Oracle Open World, Andy mentioned that he’d like to see […]

  59. satpal yadav Says:

    Frank Nimphius and Jobinesh Purushothaman is coming to Bangalore this April at Great Indian Developer Summit 2010 ( developersumit dot com) to to show how JavaServer Faces can be used to build compelling Ajax user interfaces for Web Services models giving end users a comfortable working environment that includes client side validation and user interface customization.

  60. Daniel Echeverry Says:

    Very Nice, Great Post, thank you very much! I’m impressed with the new features in JSF 2, this is an great movement since JSF 1.x, But, why the configuration of annotations like @ManagedBean are considered an optional part of JSF 2 specification? If this kind of features are just optional, the implementations of JSF like RichFaces, MyFaces, IceFaces etc. must implement it, this great features should not be widely supported and not merely optional? for example, with RichFaces JSF 2.0 support this annotation is not yet functional, making it necessary to have a faces-config.xml file to define the Managed Beans, with JSF 2.0 having the freedom to use faces-config file or not, was a feature that pleased me enough, however if you use an implementation that does not support features such options no longer have that flexibility, is something that in later release of JSF 2.0 will be fully supported?

  61. Saeed Zarinfam Says:

    Very complete. i think JSF 2 is very powerful than JSF 1.2.

  62. Dharmesh Mistry Says:

    Great overview of the new features in JSF2. This is a great starting point for getting your head wrapped around what is new. Having used JSF 1.2 this new release of the spec is a breath of fresh air!

  63. nash Says:

    Hi, is the JSF 1.2 way of creating custom components still supported in JSF 2.0 or is composite components the only way of creating components?

  64. Jonathan Welzel Says:

    Very nice post, though I’ve been wondering if there have been any changes in the JSF app lifecycle that we should be aware of? Thanks.

  65. Sarang Says:

    Respected Sir/there,

    I just want to know that if the faces-configuration is not required in jsf 2.0 then how do the dependency injection & navigation performed itself ?

    With Regards,
    Sarang Dave.

  66. RichFaces 4 Alpha Released | The Java Momentum Says:

    […] Alpha 2 was released. For an overview of what’s new in JSF2 and the possibilities, check out this blog by Andy Schwartz for a complete review with lots of links and documentation. Quote from the Richfaces Project Page […]

  67. Ravi Kiran Bhaskar Says:

    Very niice overview with the right amount of depth to make sense. Thanks a bunch, this dispelled my confusions

  68. Альтернативы JSF для Seam | Alexander Shchekoldin "all in one" blog Says:

    […] What’s New in JSF 2? […]

  69. Trying out JSF 2.0 – View scope & Spring « Bonney & Stewart Software Development Blog Says:

    […] a more detailed look at the new scopes and other features of JSF 2.0 I would recommend this blog post that I came […]

  70. Spring Web Flow 2.2.0.M1 Released | SpringSource Team Blog Says:

    […] main focus of the release is to address the needs of JSF users by extending the list of supported JSF 2 features. Not long ago Web Flow 2.1 made it possible to use JSF 2 dependencies without the need for the […]

  71. juniorsatanas Says:

    Muito bom !

  72. Pedro T. Oliveira Says:

    Thanks for the post, it help me a lot.

    Can i translate to portuguese and make reference on my blog?


  73. Pedro Oliveira Says:

    Yes of course. Ill do that.
    Thank you.

  74. Michael Peter Gower (@MichaelPtrGower) Says:

    Thank you for creating this post, excellently written.

    I just put together a blog post about HOW to upgrade to 2.0 that should help people out at Hacker’s Valhalla (http://bit.ly/vW6vTU).

  75. Akki Says:

    Thanks Andy .. I have just started using JSF 2.0 and your post has made my life easier 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: