Setting JSF ProjectStage with JNDI

One nice feature of JSF2 is the ProjectStage setting.  It lets the JSF implementation and the application developer optimize and customize behavior based on whether JSF is running in Development, Production, SystemTest, or UnitTest.  The usual way to tell JSF about which ProjectStage to use is through a context param in web.xml.

<context-param>
        <param-name>javax.faces.PROJECT_STAGE</param-name>
        <param-value>Development</param-value>
</context-param>

But you would rather not muck with web.xml for something like this.  It's much cleaner to define your ProjectStage based on what kind of server environment you are running.  In other words, wouldn't it be nice if JSF could know whether your server is running in Development, Test, Production, etc?  Then you wouldn't need to change your application at all.

A little-known but handy feature of JSF2 is the ability to use JNDI to set the JSF ProjectStage.  Here is how you do that in JBoss AS7.

First, add a resource reference in web.xml.

<resource-ref>
   <res-ref-name>jsf/ProjectStage</res-ref-name>
   <res-type>java.lang.String</res-type>
</resource-ref>

Then, create a jboss-web.xml file and place it beside web.xml in your WEB-INF directory. The file should bind the resource reference to JNDI like this:

<?xml version="1.0" encoding="ISO-8859-1"?>
<jboss-web>
    <resource-ref>
        <res-ref-name>jsf/ProjectStage</res-ref-name>
        <res-type>java.lang.String</res-type>
        <jndi-name>java:/env/jsf/ProjectStage</jndi-name>
    </resource-ref>
</jboss-web> 

Next, add the JNDI value to JBoss AS7 in the naming subsystem of your configuration file, such as standalone.xml:
      <subsystem xmlns="urn:jboss:domain:naming:1.1">
            <bindings>
                <simple name="java:/env/jsf/ProjectStage" value="Development"/>
            </bindings>
        </subsystem>

You can also add the JNDI value using CLI:

/subsystem=naming/binding=java\:\/env\/jsf\/ProjectStage/:add(binding-type=simple,value=Development,class=java.lang.String)

But I like to use CLI GUI for this because it automatically handles the escape characters:

Now we are done, but you might also want to change the value of ProjectStage on your server. Again, you can do that in XML or you can use CLI: 
/subsystem=naming/binding=java\:\/env\/jsf\/ProjectStage/:write-attribute(name=value,value=UnitTest)

Multi-JSF is here! Use any JSF in JBoss AS

Multi-JSF is a JBoss AS feature that I've wanted to implement for a very, very long time.  Basically, it allows you to use any JSF implementation as if it were the impl that ships with JBoss AS.  This works with almost any version of MyFaces or Mojarra.  You can even install multiple JSF implementations and tell each app which one to use.

Until now, if you wanted to use a different JSF version, you could hack AS7.  But this only worked for Mojarra implementations.  If you wanted to use MyFaces, you had to resort to bundling JSF with your web app and setting WAR_BUNDLES_JSF_IMPL in web.xml.

Both methods had potential integration problems if you wanted to use JEE5 features such as @EJB , or JEE6 features like CDI and bean validation.  What's worse is that if you wanted to use more than one JSF version you would end up bundling JSF with every WAR.

In short, it was messy and it didn't always work.  Plus, WAR_BUNDLES_JSF_IMPL isn't even officially supported.

Multi-JSF is now in the latest nightly build of 7.2.0-Alpha1.  You can get all the details on how to use it at  https://community.jboss.org/wiki/DesignOfAS7Multi-JSFFeature.

I hope you'll try it out and provide some feedback before AS7.2 goes final.

So long and thanks for all the fish,

Stan

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.