Java EE 6 with Fine Beers - Beer 2

This is the 2nd of several articles reporting my experiences while migrating an enterprise  application to Glassfish V3.

This post will cover the issues around migrating JSF 1.2 + RichFaces 3.x applications to Glassfish V3.

Not so hard to face it

We where happy with our JSF / RichFaces applications running in V2. Richfaces delivers high quality RIA components at a very affordable learning curve, for developers familiar to JSF.

When using Galssfish V2/Java EE 5/JSF/Facelets stack we need to include the Facelets JAR into our web application, and to activate it in faces-config.xml, more specifically with a view handler configuration.  Before migrating the application I studied JSF topics in Java EE 6 Tutorial, and found this important statement:

"As of JavaServer Faces 2.0, Facelets is a part of JavaServer Faces specification and also the preferred presentation technology"

It means that we do not need to include Facelts JAR, nor configure its view handler in faces-config.xml. So I did in the immigrant JSF application, and deployed it to V3. The error I received when I requested the JSF applications by the web browser was:
javax.servlet.ServletException: PWC1232: Exceeded maximum depth for nested request dispatches: 20

It forced me to do some research, and soon I realized that RichFaces 3.x is not compatible to JSF 2.0. We could not wait for RichFaces 4 release - that will be JSF 2 compatible - as we are very dependent on RichFaces components. Pressure meter rising...

With a further research I found some folks facing the same issue here
http://forums.sun.com/thread.jspa?threadID=5419682
and a wiki explanation here
http://wiki.glassfish.java.net/Wiki.jsp?page=JavaServerFacesRI#section-JavaServerFacesRI-IWantToUseMojarra1.2InGlassfishV3

Both explain how to do a class loader trick, via sun-web.xml, to force Glassfish V3 to use Mojarra 1.2 (JSF 1.2 reference implementation) and to keep the environment RichFaces-friendly.

It sounds nice and safe, as long as your WAR module is going to be deployed as an independent application. I discovery that this work around limits Java EE dependency injection when I read:
http://bleathem.blogspot.com/2010/01/glassfish-v2-and-v3-on-same-host-behind.html

In my case, the WAR module is deployed inside an EAR, and receive EJBs and Resource injections from sibling modules. So I managed to find more options.

Fortunatelly I received good news via twitter: RichFaces 3.3.3 beta had just been released, and there was a work around to JSF 2:
http://community.jboss.org/wiki/RichFaces333andJSF20

The article teaches how to turn off the view handler with a context-param in web.xml:

param-name: javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER
param-value: true




It didn't work right away, but at some point in the article's thread we have "Facelets 1.1.15 should still be used because of dependencies in RichFaces from the Tag Handlers classes."
Facelets 1.1.15, huh ? Researching a little further it came to me:
http://community.jboss.org/message/521844#521844

This last post elucidates the need to include jsf-facelets-1.1.15.B1.jar into WEB-INF/lib in addition to disable the Facelets View Handler. Notice, however that I didn't include jsf-api.2.x nor jsf-imp.2.x (as the proposed solution does) because it is already present in Glassfish V3.

And that's what I had to do in order to enjoy RichFaces powerful Ajax components with JSF 2.0 and Glassfish V3. We need to celebrate it with a Brazilian bier, don't we ?

Black Princess Gold


Type: Pilsen
Price: $$
Website: http://www.cervejablackprincess.com.br
Harmonizes with: Lamb