JSF 1.2 and WebSphere 6.1

We had a situation: the systems team confirmed WebSphere 7.0 deployment wasn’t feasible for our project, so we were stuck on WAS 6.1. Meanwhile, the architecture team recommended JSF 1.2 and Java EE 5 — neither officially supported on that platform.

Fun times.

The Core Issue

JSF 1.2 and WAS 6.1 don’t officially support each other. On top of that, using JSP as the view layer creates class conflicts between the WAS 6.1 JSP runtime and JSF’s component model. This combination is essentially a compatibility minefield.

Why Facelets Is the Answer

Facelets was designed specifically as a view handler for JSF. Unlike JSP, which has its own lifecycle that conflicts with JSF’s, Facelets integrates cleanly with JSF’s component model. Two key advantages:

1. It’s purpose-built for JSF — no lifecycle conflicts
2. Better performance than JSP in JSF contexts

With Facelets in the picture, the JSP conflict goes away entirely.

The Options

Option 1: WAS 6.1 + MyFaces JSF 1.1 + Facelets May require application-first class loading to ensure your bundled JSF implementation takes precedence over WAS’s built-in one.

Option 2: WAS 6.1 + MyFaces JSF 1.2 + Facelets (recommended) Definitely requires application-first class loading. More current JSF version, cleaner Facelets support.

Option 3: WAS 6.1 + Sun JSF 1.1 + JSP + RichFaces/IceFaces Least preferred. You’re back in JSP territory with all the lifecycle friction that entails.

Our Choice

Pending architecture team sign-off, Option 2. It keeps us current with JSF 1.2, leverages Facelets to eliminate the JSP conflicts, and the class-loading configuration is a one-time setup that pays for itself immediately.

The application-first class loading policy for WAS is configured in ibm-web-ext.xmi — worth documenting in your team’s deployment runbook since it’s easy to forget when setting up new environments.