JSFUnit 2.0.0.Beta 2 is Out

It's hard to believe that it has taken this long to get from Beta 1 to Beta 2. There were some good reasons for it. One is because we were waiting for Arquillian and JBoss AS7 to stabilize. The other reason is just because I haven't had as much time to work on JSFUnit as I did in the past. Most of my time has been taken up with AS7-related stuff.

However, I'm thrilled that the community has come to the rescue! In fact, the community gets almost all the credit for this release. First, there is Josè Freitas. Josè did most of the coding to get the us running with the latest Aqruillian and JBoss AS7. This included porting the CDI-based annotations to use Arquillian TestEnricher. Now, you no longer need CDI for the new annotations to work. That's a big help for containers that don't natively support CDI.

We got some further help from JBoss developers Aslak Knudsen and Andrew Lee Rubinger. Plus, there were lots of community members who stepped up to answer questions on the JSFUnit forum while I was less active. Wolfgang Knauf even went so far as to write a comprehensive tutorial on using JSFUnit Beta 2 with Eclipse.

So, what's new in the release?
You can click here for the official release notes.

In summary, we now fully support the latest version of Arquillian and added the long-awaited support for JBoss AS7. As mentioned above, the annotations no longer require CDI. And, we've moved the source code to GitHub. That should make it even easier for everyone to get involved.

Here are some helpful links to get you started:
Getting Started with JSFUnit 2.x
Getting Started Sample App
JSFUnit 2.x FAQ
JSFUnit 2.x Annotations

Hope you enjoy the release. We'll probably do one more beta soon. But with all the extra help, it shouldn't be long before JSFUnit 2 goes final.

So long and thanks for all the fish,

Stan

JSFUnit 2.0.0.Beta1 is Out

I'm very excited to announce the availability of JSFUnit 2.0.0.Beta1. The two biggest shortcomings of JSFUnit 1.x were always a lack of JUnit 4 support and relatively slow execution times compared with "mock object" solutions.

The reason we couldn't do anything about this up until now was because JSFUnit 1.x needed Cactus as the in-container test runner. Being in-container has tremendous advantages because you don't need the messy mock objects and you can run your tests against the real system. But Cactus is rather old and it only supported JUnit 3.

So now, JSFUnit 2.x takes advantage of the new in-container framework from JBoss called Arquillian. It not only supports JUnit 4, but you get TestNG support to boot. And depending on the container you choose, the speed can be really fast.

Here are the links you need to know about to get started:
Getting Started with JSFUnit 2.x
Getting Started Sample App
JSFUnit 2.x FAQ
JSFUnit 2.x Annotations

I want to thank those who have helped with this release. Thanks goes to Ole for his nifty new method to click a RichFaces panel bar item. Also thanks to Bernard Labno who has been working hard on some additional RichFaces support. His code hasn't been integrated yet but I'm confident that his work will solve some long-standing issues with ajax queues.

And last but not least, thanks to Aslak Knutsen and all his fellow contributors to the Arquillian project. You guys have been extremely helpful. I'm sure our two products will continue to complement each other and spread the gospel of in-container testing.

So long and thanks for all the fish,

Stan

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

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.

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.

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

What's a WARlet ???

JSFSpy Progress
Today I uploaded a new snapshot of JSFSpy. BTW, I'm keeping the name JSFSpy. Even though I don't like it that much, it's short and to the point. Thanks to those who had other suggestions earlier this year. JSFSpy is super-easy to install. Just drop the JSFSpy core jar into your WEB-INF/lib and you are ready to go. Click here for details.

What's a WARlet ???
In short, a WARlet is a WAR plug-in. It provides one or more Facelet views via a WARlet container and some Servlet 3/JSF 2 magic. A WARlet is neatly packaged in its own jar. The jar contains any xhtml, css, images, and classes that it needs. This provides a module of UI and processing logic that you can add to your WAR with zero configuration.

If you happened to catch my JSFSpy presentation at JSF Summit a couple of weeks ago, you saw a WARlet in action. I'll re-create that demo here. Notice the JSFSpy menu buttons at the top:


I took JSFSpy and bundled the WARlet container along with it. Then I took my EL_Evaluator WARlet jar and dropped that into WEB-INF/lib. Redeploy and Viola!! Now an EL Evaluator button appears in my application on the far right.


The button can launch the EL Evaluator functionality. Here is the EL Evaluator:


So how does the button get added? JSFSpy doesn't know anything about EL Evaluator. It only knows that one or more WARlets might be present. So the button menu has this markup to display a launch button for any WARlets that happen to be there:


So what this all means is that anyone in open-source land can create their own WARlet that plugs into JSFSpy. I'll be posting more about how to create a WARlet in the near future. If you just can't wait to write your own you can browse the JSFSpy source, example code, and WARlet container source.

The only catch is that all this requires Servlet 3.0 and JSF 2.0. Nothing wrong with the bleeding edge, eh?

So long, thanks for all the fish, and have a great holiday!

Stan