Matt Raible has been building web applications for most of his adult life. He started tinkering with the web before Netscape 1.0 was even released. For the last 16 years, Matt has helped companies adopt open source technologies (Spring, Hibernate, Apache, Struts, Tapestry, Grails) and use them effectively. Matt has been a speaker at many conferences worldwide, including Devoxx, Jfokus, ÜberConf, No Fluff Just Stuff, and a host of others. Matt is a DZone MVB and is not an employee of DZone and has posted 144 posts at DZone. You can read more from them at their website. View Full User Profile

Upgrading to JSF 2

  • submit to reddit
Last week, I spent a few hours upgrading AppFuse from JSF 1.2 to JSF 2.0. In reality, I upgraded from MyFaces 1.2.7 to 2.0.4, but all JSF implementations should be the same, right? All in all, it was a pretty easy upgrade with a few minor AppFuse-specific things. My goal in upgrading was to do the bare minimum to get things working and to leave integration of JSF 2 features for a later date.

In addition to upgrading MyFaces, I had to upgrade Tomahawk by changing the dependency's artifactId to tomahawk20. I was also able to remove the following listener from my web.xml:


After that, I discovered that MyFaces uses a new URI (/javax.faces.resource/) for serving up some of its resource files. I kindly asked Spring Security to ignore these requests by adding the following to my security.xml file.

<intercept-url pattern="/javax.faces.resource/**" filters="none"/>

Since JSF 2 includes Facelets by default, I tried removing Facelets as a dependency. After doing this, I received the following error:

ERROR [308855416@qtp-120902214-7] ViewHandlerWrapper.fillChain(158) | Error instantiation parent Faces ViewHandler
java.lang.ClassNotFoundException: com.sun.facelets.FaceletViewHandler
        at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(
        at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(
        at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(
        at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(
        at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(
        at org.ajax4jsf.framework.ViewHandlerWrapper.fillChain(
        at org.ajax4jsf.framework.ViewHandlerWrapper.calculateRenderKitId(
        at org.apache.myfaces.lifecycle.DefaultRestoreViewSupport.isPostback(
        at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(
        at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(
        at javax.faces.webapp.FacesServlet.service(

Figuring this was caused by the following element in my web.xml ...


... I removed it and tried again. This time I received a NoClassDefFoundError:

java.lang.NoClassDefFoundError: com/sun/facelets/tag/TagHandler
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(
        at java.lang.ClassLoader.defineClass(
        at Method)
        at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(
        at org.mortbay.jetty.webapp.WebAppClassLoader.loadClass(
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(
        at org.apache.myfaces.shared_impl.util.ClassUtils.classForName(
        at org.apache.myfaces.view.facelets.util.ReflectionUtil.forName(

Since everything seemed to work with Facelets in the classpath, I decided to save this headache for a later date. I entered two issues in AppFuse's JIRA, one for removing Facelets and one for replacing Ajax4JSF with RichFaces.

The next issue I encountered was redirecting from AppFuse's password hint page. The navigation-rule for this page is as follows:


With JSF 2.0, the rule changes the URL to /login.xhtml when redirecting (where it was left as /login with 1.2) and it was caught by the security setting in my web.xml that prevents users from viewing raw templates.

<web-resource-name>Protect XHTML Templates</web-resource-name>

To solve this issue, I had to make a couple of changes:

  • Comment out the security-constraint in web.xml and move it to Spring Security's security.xml file.
    <intercept-url pattern="/**/*.xhtml" access="ROLE_NOBODY"/>
  • Add a rule to urlrewrite.xml that redirects back to login (since login.xhtml doesn't exist and I'm using extensionless URLs).
    <rule match-type="regex">
    <to type="redirect">%{context-path}/login</to>

After getting the Password Hint feature passing in the browser, I tried running the integration tests (powered by Canoo WebTest). The Password Hint test kept failing with the following error:

[ERROR] /Users/mraible/dev/appfuse/web/jsf/src/test/resources/web-tests.xml:51: JavaScript error loading
page http://localhost:9876/appfuse-jsf-2.1.0-SNAPSHOT/passwordHint?username=admin: syntax error (http://

Figuring this was caused by my hack to submit the form when the page was loaded, I turned to Pretty Faces, which allows you to call a method directly from a URL. After adding the Pretty Faces dependencies to my pom.xml, I created a src/main/webapp/WEB-INF/pretty-config.xml file with the following XML:

<pattern value="/editProfile"/>
<view-id value="/userForm.jsf"/>

<pattern value="/passwordHint/#{username}"/>
<view-id value="/passwordHint.jsf"/>

This allowed me to remove both editProfile.xhtml and passwordHint.xhtml, both of which simply auto-submitted forms.

At this point, I figured I'd be good to go and ran my integration tests again. The first thing I discovered was that ".jsf" was being tacked onto my pretty URL, most likely by the UrlRewriteFilter. Adding the following to my class solved this.

if (username.endsWith(".jsf")) {
username = username.substring(0, username.indexOf(".jsf"));

The next thing was a cryptic error that took me a while to figure out.

DEBUG [1152467051@qtp-144702232-0] PasswordHint.execute(38) | Processing Password Hint...
2011-03-05 05:48:52.471:WARN::/passwordHint/admin
com.ocpsoft.pretty.PrettyException: Exception occurred while processing <:#{passwordHint.execute}> null
        at com.ocpsoft.pretty.faces.beans.ActionExecutor.executeActions(
        at com.ocpsoft.pretty.faces.event.PrettyPhaseListener.processEvent(
        at com.ocpsoft.pretty.faces.event.PrettyPhaseListener.afterPhase(
        at org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersAfter(
        at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(
        at javax.faces.webapp.FacesServlet.service(

Digging into the bowels of MyFaces, I discovered a class was looking for a viewId with an extension and no view-id was being set. Adding the following to the top of my execute() method solved this.


After making this change, all AppFuse's integration tests are passing and the upgrade seems complete. The only other issues I encountered were logging-related. The first is an error about Tomahawk that doesn't seem to affect anything.

Mar 5, 2011 6:44:01 AM com.sun.facelets.compiler.TagLibraryConfig loadImplicit
SEVERE: Error Loading Library: jar:file:/Users/mraible/.m2/repository/org/apache/myfaces/tomahawk/tomahawk20/1.1.10/tomahawk20-1.1.10.jar!/META-INF/tomahawk.taglib.xml Error parsing [jar:file:/Users/mraible/.m2/repository/org/apache/myfaces/tomahawk/tomahawk20/1.1.10/tomahawk20-1.1.10.jar!/META-INF/tomahawk.taglib.xml]: 
        at com.sun.facelets.compiler.TagLibraryConfig.create(
        at com.sun.facelets.compiler.TagLibraryConfig.loadImplicit(
        at com.sun.facelets.compiler.Compiler.initialize(
        at com.sun.facelets.compiler.Compiler.compile(

The second is excessive logging from MyFaces. As far as I can tell, this is because MyFaces switched to java.util.logging instead of commons logging. With all the frameworks that AppFuse leverages, I think it has all the logging frameworks in its classpath now. I was hoping to fix this by posting a message to the mailing list, but haven't received a reply yet.

[WARNING] [talledLocalContainer] Mar 5, 2011 6:50:25 AM org.apache.myfaces.config.annotation.TomcatAnnotationLifecycleProvider newInstance
[WARNING] [talledLocalContainer] INFO: Creating instance of org.appfuse.webapp.action.BasePage
[WARNING] [talledLocalContainer] Mar 5, 2011 6:50:25 AM org.apache.myfaces.config.annotation.TomcatAnnotationLifecycleProvider destroyInstance
[WARNING] [talledLocalContainer] INFO: Destroy instance of org.appfuse.webapp.action.BasePage

After successfully upgrading AppFuse, I turned to AppFuse Light, where things were much easier.

Now that AppFuse uses JSF 2, I hope to start leveraging some of its new features. If you're yearning to get started with them today, I invite you to grab the source and start integrating them yourself.


Published at DZone with permission of Matt Raible, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Jonathan Fisher replied on Tue, 2011/03/08 - 12:24pm

Matt, take a look at Primefaces instead of MyFaces... It's still a rather green project, but it's more of a pure JSF2.0 implementation. Essentially the project drives JQueryUI on the client side, making it very dynamic right out of the box.

Matt Raible replied on Tue, 2011/03/08 - 12:44pm in response to: Jonathan Fisher

AFAIK, PrimeFaces is just a component library, not a JSF implementation. So it's more akin to MyFaces Tomahawk than MyFaces (the implementation). I'd love to see a comparison of PrimeFaces, RichFaces and ICEfaces.

Max Katz replied on Tue, 2011/03/08 - 12:57pm in response to: Jonathan Fisher

As Matt said, PrimeFaces is just a component library on top of JSF 2. RichFaces 4 is also based on jQuery. It uses a more hybrid approach. Instead of just wrapping a JavaScript widget as JSF component, some of the JavaScript functionality is developed in-house.

Cagatay Civici replied on Tue, 2011/03/08 - 3:11pm

Correction: PrimeFaces does not "just" wrap javascript widgets, there are many components that are developed in-house like tree, datatable, picklist, toolbar, form controls, panels and many more. Also it has first class JSF 2.0 support almost a year.

George Jiang replied on Tue, 2011/03/08 - 9:48pm in response to: Max Katz


 RichFaces 4 is also based on jQuery.


What do you mean by that?

George Jiang replied on Tue, 2011/03/08 - 9:54pm in response to: Cagatay Civici

What is the advantage of PrimeFaces comparing to RichFaces? PrimeFaces supported JSF1.2 before, so I suppose it isn't a brand new libarary for JSF 2.0 either?

Max Katz replied on Tue, 2011/03/08 - 11:27pm in response to: George Jiang

The core JavaScript framework in RichFaces 4 is jQuery.

George Jiang replied on Wed, 2011/03/09 - 11:50pm in response to: Max Katz

I used RichFaces 3 (especially the a4j tags) in a project to develop a large Intranet application with lots of ajax and only a handful of navigation. Never found the need to write javascript. Maybe the legacy Oracle forms 4GL application we were replacing sets the bar too low :-)

I actually prefer the a4j:support to the new JSF2 f:ajax. Since with a4j:support's action attribute, I can specify arbitary method calls (with arguments!) such as <a4j:support action=#{,b)}/>. But with JSF2's f:ajax you can only specify a method which takes a single parameter, i.e., an ActionEvent object.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.