Tuesday, December 28, 2010

JSF on JBoss AS6 Final

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

Wednesday, August 11, 2010

JSFUnit 1.3.0.Final is Released

A Small Release with Big Consequences

JSFUnit 1.3.0 is out. There are only three interesting changes:
  • A new API call on RichFacesClient for Drag and Drop
  • Updates for compatibility with HtmlUnit 2.8
  • One JSFUnit bug fix
The Drag and Drop thing is nice. And HtmlUnit 2.8 fixes a LOT of the bugs from 2.7, several of which were reported by the JSFUnit community.

But the big story is the one tiny JSFUnit bug fix submitted by Aslak Knudsen. You see, that fix enables JSFUnit to integrate with Arquillian. If you are not familiar with Arquillian, this is a new JBoss project that handles deployment and test execution for in-container tests. It's an elegant, modern replacement for what we do now with Cactus and Cargo.

So going forward, you will be able to run your JSFUnit tests using either Arquillian or Cactus/Cargo. The advantages you will have with Arquillian are:
  • Full JUnit 4 support (yay! we can finally use the @Test annotation!)
  • TestNG 5 support (yay! if you prefer TestNG)
  • Resource injection into your test classes (stuff like @Inject or @EJB can go right into your test)
  • Testing for subsets of your WAR. For instance, if I only want to test two facelets and one managed bean it will package those into a small WAR, deploy it, and run the test. This is great for development because single tests will run much faster without creating the whole giant WAR.
The one disadvantage I can think of is that Cargo supports more containers. Arquillian currently supports JBoss AS, Glassfish, Jetty, and Tomcat. But I'm sure more are on the way.

So when can you try out the JSFUnit/Arquillian combo? Aslak already has a proof of concept. It looks like we may be ready to let it loose in just a few days. Stay tuned.

So long, and thanks for all the fish,

Stan

P.S. Note that some dependency versions have changed. Check out the getting started page for the complete list of jars you need to upgrade.

Tuesday, March 16, 2010

A Patent on JSFUnit

... or more precisely, I/we patented one of the key technologies JSFUnit uses. About the same time I was starting the JSFUnit project, Red Hat's lawyers announced a push to get us to file software patents. I did so reluctantly because I think that in the end, software patents are a game that only the lawyers can win. But Red Hat has a good strategy when it comes to patents that I think ultimately benefits everyone. Read below for more on that.

So it took over three years to get it done. You can view the patent here if you want the gory details.


What does the patent say?
Basically, it just says that we keep the FacesContext alive after the request is done. Without JSFUnit, the JSF Lifecycle would throw it away. That lets us do assertions on the state of the system after each JSF request. If you've been using JSFUnit then you probably know all about that. It's what makes JSFUnit unique among testing tools.


What does the patent mean for JSFUnit users?
Nothing. The software is still open source. We're not looking to make money off of the patent.


Why did Red Hat want to patent this in the first place? Doesn't this go against Red Hat's philosophy of openness and freedom?
Yes and no. Red Hat doesn't really like software patents either. But we see them as a necessary evil until some laws are changed. As I understand it, the Red Hat Patent Promise says that anyone can use our patents for free as long as you don't file a patent case against us.

So long and thanks for all the fish,

Stan

*Disclaimer: I'm not an attorney. The above is my own understanding of this stuff. I'm not even qualified to write this disclaimer.

Wednesday, March 3, 2010

JSFUnit 1.2 Goes Final

We just put out a new release of JSFUnit. This time besides bug fixes, we have few new features to talk about:
  • JSF Static Analysis Returns - A big thank-you goes to our newest committer, Alexander Jesse. He has updated some of the old JSF static analysis code and made it really easy to test your JSF configuration for common errors. Some of the old static analysis stuff is still there but his ConfigFilesTestSuite looks awesome. Click here to check out the documentation.
  • New API for working with RichTree components - Of all components, developers using JSFUnit seem to have the most difficulty with RichTree. That's understandable because it is a very complex component. In JSFUnit 1.2.0 the RichFacesClient has new methods for working with RichTree. You can read about that here.
  • Easier Configuration for Servlet 3.0 - If you are lucky enough to be using a Servlet 3.0 container such as JBoss AS6, you no longer need to change your web.xml. JSFUnit will add the needed servlets and filters at deploy time.
  • JSFUnit Console - This is one of the cooler new features, but it also requires Servlet 3.0. JSFUnit now provides a browser-based console for launching your tests. You don't have to do anything extra. You just need to deploy your app and type http://locahost/myjsfapp/jsfunit into the browser. You can read all about it here.
A note about upgrading. If you are upgrading from JSFUnit 1.1.0 you will need to upgrade some of your jars that you package with the WAR. They are:
  • htmlunit-2.7.jar
  • htmlunit-core-js-2.7.jar
  • nekohtml-1.9.14.jar
  • commons-codec-1.4.jar
Also, there have been a few bug fixes in HtmlUnit for RichFaces. So if you run into trouble you can find an HtmlUnit 2.8 snapshot from the latest build that contains the fixes.

As always, thanks to everyone who contributed to this release with patches and feedback.

So long and thanks for all the fish,

Stan