StackOverflow Exception Upgrading to JSF 2.0

Take a look at the following recursive stack trace which came up whenever I tried to fetch a page after upgrading to JSF 2.0:

	javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
	com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:546)
	com.sun.faces.application.view.JspViewHandlingStrategy.executePageToBuildView(JspViewHandlingStrategy.java:363)
	com.sun.faces.application.view.JspViewHandlingStrategy.buildView(JspViewHandlingStrategy.java:154)
	com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
	com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
	com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:546)
	com.sun.faces.application.view.JspViewHandlingStrategy.executePageToBuildView(JspViewHandlingStrategy.java:363)
	com.sun.faces.application.view.JspViewHandlingStrategy.buildView(JspViewHandlingStrategy.java:154)
	com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:100)
	com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
	com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
	javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)

Of course the whole thing eventually blows up into a StackOverflowError. But how did it happen? Even the simplest page gave me the same behaviour.

Well, when I was using JSF 1.2 with Facelets I didn't really get why you should use .jsf in your URLs but .xhtml in your files, so I added the following to my web.xml which allowed me to use .xhtml for both URLs and files.

    <context-param>
        <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
        <param-value>.xhtml</param-value>
    </context-param>

Now, in JSF 2.0 for some reason this setting only applies to the JSP ViewHandler. So what was happening was the JSP ViewHandler was handling my requests and forwarding them to the appropriate .xhtml resource, which was handle by the JSP ViewHandler which would forward them to yes, the JSP ViewHandler... ad infinitum.

There is an easy fix. You just need to use javax.faces.FACELETS_SUFFIX instead:

    <context-param>
        <param-name>javax.faces.FACELETS_SUFFIX</param-name>
        <param-value>.xhtml</param-value>
    </context-param>

UPDATE: This problem was actually caused by Tomahawk 1.1.5 and placing tomahawk.taglib.xml in the classes/META-INF directory. The runtime autoloading of taglib files seems to be flakey and classpath dependent. When the taglib can't be found, tomahawk causes the JSPViewHandler to be selected, although I'm not sure why.

The workaround is to specify the tomahawk taglib explicitly in web.xml, e.g:

  <context-param>
    <param-name>javax.faces.FACELETS_LIBRARIES</param-name>
    <param-value>
      /apps/webcore/tags/_mytags.taglib.xml;
      /apps/webcore/tags/_tomahawk.taglib.xml;
    </param-value>
  </context-param>

About Roger Keays

Roger Keays is an artist, an engineer, and a student of life. He has no fixed address and has left footprints on 40-something different countries around the world. Roger is addicted to surfing. His other interests are music, psychology, languages, the proper use of semicolons, and finding good food.