Red Hat
Dec 28, 2010
by Stan Silvert
When I do blog here, it's usually about JSFUnit. But today it's time for me to blog about the other stuff I do at JBoss. Besides JSFUnit, I'm also responsible for JSF integration in the JBoss Application Server. With JBoss AS6 going final, I'd like to talk about some big improvements.

A short history of JSF on JBoss AS
JSF has been integrated into JBoss AS since version 4.0.3. Back then we were using MyFaces 1.1. All it really meant was that JSF would be on the classpath so you didn't need to bundle JSF with your WAR any more. The integration was so crude that you still had to declare the MyFaces context listener in your own web.xml.

With JBoss AS4.2 and AS5, integration got tighter. We switched to Sun's JSF 1.2 implementation, now known as Mojarra. JSF 1.2 included support for JEE5 annotations on your managed beans such as @PostConstruct, @PreDestroy, and @Resource. It also included integration with JSP and EL. And, you no longer had to declare a listener in your own web.xml.

Despite better integration and more features, some people got mad. You see, even though MyFaces and Mojarra comply with the same spec and pass the same TCK, they are not 100% compatible. So apps that ran fine on AS4.0.3 broke on AS4.2 and AS5. What's more, the reality is that JSF apps are not even fully compatible from version to version. Apps that run fine on Mojarra 1.2 might not run on Mojarra 2.0.

And don't even get me started about JSF component libraries. Suffice it to say that compatibility between versions and implementations is even worse.

JSF on AS6: Coming to grips with reality
The reality is that an application server needs to play nice with more than one JSF implementation. So with AS6, we ship with three versions of JSF. Mojarra 2.0 is there as the default implementation. Mojarra 1.2 is there to ease migration from AS5. And, MyFaces 2.0 is there for those who prefer MyFaces. To choose a different JSF, all you need to do is declare a single context param in your web.xml like this:
<context-param>
<param-name>org.jboss.jbossfaces.JSF_CONFIG_NAME</param-name>
<param-value>Mojarra-1.2</param-value>
</context-param>

But it doesn't stop there. If you want to bundle JSF with your WAR like in Tomcat, that's fine. If you want to add a fourth JSF version to JBoss AS and make it the default, that's easy to do.

You can even bundle a component library together with a particular JSF version and call that "MyPerfectJSFConfig". Then refer to the JSF Config in web.xml for all your apps that use that. No need to bundle RichFaces or IceFaces jars over and over with every WAR:
<context-param>
<param-name>org.jboss.jbossfaces.JSF_CONFIG_NAME</param-name>
<param-value>MyPerfectJSFConfig</param-value>
</context-param>


This is all really handy for testing your application against different JSF versions and implementations. Ever ask yourself if your Mojarra app would run faster (or without errors) on MyFaces? Now it's easy to find out. What if you have an old app that runs on JSF 1.2 but you also have a new app that runs on JSF 2.0? You don't have to worry that the upgrade to JSF 2.0 will break the old app. They can run side-by-side in the same JBoss AS instance without changes.

If you want the details on how to do this stuff, take a look at the JSF on AS6 documentation.

All this and more
I don't want to leave out the fact that all the JEE integration you expect will be there. If you are using JSF 1.2 you will get the EE5 features like annotations on your managed beans. If you are using JSF 2.0 you will also get EE6 features like Bean Validation.

In summary, I'm really proud of the JSF integration in AS6. It took a lot of work to get this level of flexibility. And I can honestly say that every JSF integration complaint I heard in previous JBoss versions is now fixed and addressed. Onward now to JBoss AS7.

So long, and thanks for all the fish,

Stan