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.

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

JSFUnit Podcast on JSFCentral

Kito Mann just posted a podcast of yours truly on JSFCentral. It was recorded at a JSF Conference almost a year ago when JSFUnit was still in beta. But you might still find it interesting:
http://www.jsfcentral.com/articles/silvert-08-09.html

I'll be speaking at the conference again this year in Orlando. Hope to see you there.
http://www.jsfsummit.com

So long and thanks for all the fish,

Stan

JSFUnit 1.1.0.GA is released

The latest JSFUnit release is now out. This is primarily a bug-fix release, with several of these fixes related to Seam. The only significant new feature is the ability to parameterize your tests.

We now recommend using HtmlUnit 2.5 instead of 2.4. Also, everything is updated to the latest beta version of JSF 2. So now you can use JSFUnit with JSF 1.1, JSF 1.2, and JSF 2.0 Beta 2.

As for JSF Spy (JSF Eye?), this is not ready for a release. It will probably become its own separate project soon.

So long, and thanks for all the fish,

Stan

Help Me Name My Baby

I've got a new baby and I don't know what to name it. It's a new JSF debug/trace/performance tool. If you've ever seen the Facelets or Seam debug page then you've got an idea of what it is. However, this tool goes beyond those to take "state snaps" before and after each phase. And, it keeps all the info from every request and every session, even expired sessions.

Pre-alpha documentation and download is here.

So now you can debug those nasty AJAX components that do four or five JSF requests with every mouse click. You see all the HttpServletRequest data like params, headers, and cookies. And, you can look at the performance data for each request and each phase.

For now, we store this info in memory for you to peruse at your leisure. Later, I'll probably look at other options like saving to a database. That way, it might be a fit tool for production auditing.

So right now you are either thinking this is really cool or really nuts. Judge for yourself, and let me know. And if you have a good name for it please let me know that too. Right now I'm calling it JSFSpy, but I really don't like that name.

There is no dependency on JSFUnit. Installation just requires dropping a single jar into the WEB-INF/lib of your application. But you can do assertions on the collected data from JSFUnit or you can just browse it with the UI. If you want to use the UI, you'll need to put some xhtml files in your web app. Instructions are here.

Here are the screen shots that should tell you exactly what it does. There's more stuff to add like Seam scopes, JSF2 scopes, component tree, and FacesMessages. What do you think so far?


Main screen shows all HttpSessions ever created.



Request view shows all Http/JSF requests for the selected session.


Scoped Data view shows toString() value of each scoped attribute before and after each phase.


HttpServletRequest view shows incoming URL, headers, request params, cookies, etc.


Perf Data View shows which phases completed and how long each one took.

JSFUnit goes GA

I'm very happy to report that the JSFUnit 1.0.0.GA release is now out!

JSFUnit is the only end-to-end BlackBox/WhiteBox testing solution for JSF. Your tests run in-container and out-container at the same time. That is, JSFUnit lets your tests submit real HTTP requests using a headless browser. Then it lets you examine all the artifacts inside the container including the FacesContext, Managed Beans, UIComponent tree, FacesMessages, and much more. And since you are running inside the real container you never need a mock object or stub. You never have to worry about constructing a fake test environment.

Most of you reading this blog have heard all that stuff before, so I'll just talk a bit about the GA release. Here are the main changes from the Beta 3 release.

• The conversion to HtmlUnit is now complete. The old client side API based on HttpUnit is completely gone. Since HtmlUnit is far better at handling javascript, this means that most JSF AJAX libraries will work right out of the box. The notable exception is ICEfaces, and I've been working with ICEfaces team to get support for that as soon as possible.
• We now have a JSFUnit deployer for JBoss AS5. I blogged about this earlier. This deployer lets you run your JSFUnit tests without making a single change to your WAR. Click here for details.
• JSF 2.0 support. I know you are wanting to play around with JSF 2.0, right? Now you don't have to give up test-first development while you explore.
• The last change is a bit of sad news. The two developers who were working on the JSFUnit static analysis tool have moved on to new jobs where they are no longer using JSF. I versioned the code to 1.0 along with everything else, but I do want everyone to be aware that new features and bug fixes for static analysis won't happen until someone else steps up. If you are interested in taking this on let me know. JSF static analysis is really cool stuff and it's a very useful tool.

Lastly, I want to thank everyone who helped make JSFUnit happen. This is a new kind of tool that required a lot experimentation before we got it right. It has taken much longer to get here than I expected. The community feedback has been great and I've gotten tremendous support internally at JBoss/RedHat. So, in no particular order, thanks to Brian, Dennis, Jason, Matt, Shelly, Julien, Kragoth, Wolfgang, Patrick, Dimitris, Farah, Sacha, Kito, Pete, Ed, Ryan, Alexander, Jesper, Neil, Ken, and a bunch of others I've probably forgotten.

So long, and thanks for all the fish,

Stan

JSF 2.0 and the upcoming GA release of JSFUnit

I don't work on JSFUnit full time. A big part of my responsibility at JBoss/Red Hat is to make sure that JSF and Seam integrate nicely with the JBoss Application Server.

So I've been looking at the JSF 2.0 Public Review release. Using JSF 2.0 with JBoss AS 4.2 and AS 5.0 seems to be just a matter of replacing jsf-api.jar and jsf-impl.jar. I'm sure that I'll come across some things that need more/better integration. And when I do, I'll have to implement something new. But for now I'm happy to be able to play with the JSF 2.0 PR release as-is on JBoss AS.

To see how much would run without error, I decided to go ahead and upgrade JSFUnit to work with the new JSF 2.0 API. That required adding methods to JSFUnitFacesContext and JSFUnitExternalContext. There were some other code changes, including a change to the Environment class that detects which version of JSF is running.

Anyhow, I'm happy to report that JSFUnit now works with JSF 2.0. You can download the latest JSFUnit snapshot if you'd like to play with it. The part of the JSFUnit test suite that doesn't run is execution of the applications that use Facelets and Ajax4Jsf/RichFaces together. I've filed a bug on it, so hopefully that problem will be resolved soon. Please leave me feedback on the JSFUnit Forum if you decide to give it a try.

Lastly, I've been asked several times when JSFUnit is going to go GA. There is really nothing stopping me now except that I'd like to fix a few more bugs and maybe add support for IceFaces. Look for a release in mid-February.

So long and thanks for all the fish,

Stan

JSFUnit experience required

The JSFUnit project has reached a new milestone. This is the first job posting I've seen where JSFUnit experience is required.

http://www.bidtowork.com/2008/10/09/java-test-engineer-with-jsfunit-and-httpunit-experience-odesk/

So long and thanks for all the fish,

Stan

JSFUnit the Easy Way!!

JSFUnit tests are easy to write and understand. This comes across clearly whenever I talk about it at a conference and I see faces light up. They "get it". However, it's also clear that the hardest part of JSFUnit is getting started. Once you get over that hump, developers really like the tool. But until now, setting up JSFUnit for the first time required quite a bit of work.

Enter the new JSFUnit deployer for JBoss AS 5. Now, here is all you need to do to set up JSFUnit for testing:

1. Copy jboss-jsfunit-microdeployer.jar to /server/default/deployers
2. Rename your war with a "-jsfunit" suffix (such as "mywar-jsfunit.war")
3. Add your test classes to the WAR or put them in /server/default/jsfunitTests
4. Restart JBoss AS 5 and run your tests.

That's it. In fact, with a simple edit to the deployer's descriptor you can even get rid of step 2.

This is all made possible because of the redesigned microcontainer of JBoss AS 5. You can take an ordinary WAR and add servlets, filters, and classes on the fly as it is being deployed. I've been wanting this kind of functionality for as long as I can remember. It's perfect for adding test tools, fixtures, or monitoring. Before now you had to bundle this stuff with the application - stuff that really doesn't belong in your WAR.

The interesting part is that now instead of thinking of a WAR or EAR as "my application", we can truly think of it as a reuseable deployment unit. It's just another component that can be decorated or combined with other components. While this view provokes a lot of questions (security, name collisions, etc.), the mind reels with the possibilities that this represents.

So long, and thanks for all the fish,

Stan

JSFUnit Beta 3 is out. Seam support and more!

JSFUnit Beta 3 is now released. Special thanks to our new committer Brian Gregory for helping with the conversion from HttpUnit to HtmlUnit as our client side technology (see previous post). Also, the HtmlUnit team has been very helpful with answering questions and providing bug fixes.

Click http://wiki.jboss.org/wiki/JSFUnitBeta3Changes for details on new features. Unlike Beta 2, there are many goodies in this release, including support for Seam conversation scope!

If you are a Beta 2 user it is very important that you click the above link and read about the deprecated APIs that will be removed before GA. The next planned release will be 1.0.0.GA which should be out before the end of the year.

See this page for download information: http://www.jboss.org/jsfunit/downloads.html. Keep all the valuable feedback coming. It is greatly appreciated!

See you at JSFOne next week.

So long, and thanks for all the fish,

Stan

Another JSFUnit Beta Coming Soon

And why we dumped HttpUnit for HtmlUnit

We will release JSFUnit Beta 3 before the start of JSFOne on Septemeber 4th. If all goes well, it will probably be out a week or so before that.

Originally, I planned to have the GA release out by now. But the opportunity to improve the JSFUnit tool was too great to pass up. That opportunity came in the form of HtmlUnit. HtmlUnit bills itself as "a headless browser". This is exactly what I've been searching for. That is, a way to truly simulate a user interacting with a JSF application - even one that includes AJAX components.

Up until now, JSFUnit used HttpUnit to submit client requests. And HttpUnit is good at that. But HttpUnit is old, and it's mostly a dormant project. It doesn't support the latest DOM specs. And worst of all, its javascript support is dismal. This makes testing JSF/AJAX applications very difficult. In fact, the javascript support was so bad I had to just turn it off. When testing a JSF/AJAX component I would have to simulate the javascript using Java and then formulate the resulting HTTP request myself. It became clear that it would be too hacky and time-consuming to keep doing things that way.

So for JSFUnit Beta 3, I've written a new version of the JSFClientSession class that uses HtmlUnit instead. With HtmlUnit, we can execute javascript and let that javascript submit to the server. No fuss, no muss.

HtmlUnit is still pretty new, so we've found our share of bugs along the way. But unlike HttpUnit, HtmlUnit has an active core of developers who are working closely with the JSFUnit team to fix problems quickly as possible. Thus, we're doing one last beta release instead of the planned GA.

For Beta 3, you can still use the old HttpUnit-based JSFClientSession and things will work fine. This allows our early adopters to migrate their tests to the new client one at a time. But HttpUnit will be completely gone from JSFUnit for GA. So you do need to migrate before then. The new stuff is in its own package called org.jboss.jsfunit.jsfsession. This replaces the old code in org.jboss.jsfunit.facade.

That's all the news for now. So long, and thanks for all the fish.

Stan

More JSFUnit on the Road

First Up, Jazoon '08
JSFUnit is hitting the road once again, but this time, it's not me doing all the hitting. Alexander Jesse of Credit Suisse will be giving a JSFUnit introduction at Jazoon next week in Zurich. If you are in Zurich on Tuesday, June 24th be sure to check it out. Jazoon offers one-day passes.
Click Here for More Details

Second Up, JSF One '08
I'll be doing at least one talk on JSFUnit at JSF One. This is the first dedicated JSF conference in North America. So if you are into JSF, you won't want to miss it. This is scheduled for September 4th in Vienna, VA (close to Washington, D.C.). And, you get two for the price of one because admission to JSF One also gets you into The Rich Web Experience conference.
Click Here for More Details or visit www.jsfone.com.

By the time JSF One rolls around, we should have a GA version of JSFUnit out. But more on that later.

So long, and thanks for all the fish,

Stan

Cactus 1.8 is released

Congratulations to Petar Tachiev on the release of Cactus 1.8. This is the first release of Cactus in over 3 years. Thanks to Petar for taking over as project lead and getting a new release out the door. This release appears to cover mostly bug fixes and Cargo integration, which allows support of more containers.

He's also updated the build so that both Cactus and its web site are built using Maven.

See the Cactus Site for details.

If you've been following JSFUnit, you know that it is built on Cactus, so I'm very happy to see that project come back to life.

Life goes on for JSFUnit as well. The JSFUnit forum has been very popular lately and folks have been anxious to get their hands on a new release. So I'm planning a second beta release for next week. This will be mostly bug fixes, but it will include some new features as well.

Unfortunately, major new features like Seam support will have to wait for 1.0 final. We've made some progress, but it's not ready for prime time. Also, if you have a new feature that you really need in JSFUnit, make it known in the forum thread here. I'll do my best to make sure that new features are community-driven.

So long, and thanks for all the fish,

Stan