Saturday, April 3, 2010

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
and a wiki explanation here

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:

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:

The article teaches how to turn off the view handler with a context-param in web.xml:
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:

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: $$
Harmonizes with: Lamb


  1. This app didn't contain any Seam portions did it? Just straight JSF + Richfaces?

  2. Nice beer! I love that one! (That's such a small world)

    Did you use a lot of RF components or just DataTable + few others? I have this scenario, but I guess it's easier to create a plain JSF datatable with JSF2 ajax - that suits my simple needs.

  3. Does the rich:fileUpload component work after migration. We get method not found.