Wednesday, October 10, 2012

Back From Java One

Last week I was at Java One, where I can easily say I thoroughly enjoyed the week of chaos that is JavaOne. The quality of people and content was truly astounding – I met a number of people I’d been wanting to meet for a while, and also spent some time getting to know more fellow JBoss developers. I spent the bulk of my time preparing my presentations, leaving little time to attend sessions. Hopefully this extra effort paid off ;)

JBoss Booth Sessions.

The first talk I gave was an impromptu one, filling in a last-minute vacancy in the schedule. I delivered a trimmed down version of the Mobile JSF talk I gave at JBW and JAX last June/July. The talk was well received, “trapping” a fair amount of traffic around the booth, and resulting in some interesting discussion at the end of the session. The slides from this session are available, and the session was filmed – I’ll follow up with links when the videos are available.

My second talk was also a booth session. This time I presented on Leveraging jQuery plugins to build JSF components. This talk demonstrates how to build custom JSF components using first the JSF 2 composite component feature, then the RichFaces CDK. Unfortunately this session was less well attended, which I think had a lot to do with the early morning-timing.

JavaOne Session

Hot dog at Pearl Jam party
Chili dog served at the JavaOne Appreciation Event

Finally I presented a JavaOne session with Lincoln Baxter III on the topic of Testing JSF Applications with Arquillian and Selenium. This slide was recorded, and the videos is available for online viewing. Additionally I’ve posted the slides on my website, and the source code used for the demos is available on github.

The JavaOne session went really well. I was not expecting the audience to be so unfamiliar with Arquillian, given how many times Arquillian was presented at JavaOne. As such we spent more time going over the Arquillian Basics, and this cut quite a bit into the time I wanted to spend on the JSF specific Arquillian Warp slides near the end of the presentation. Nevertheless, the message was well received, and we’ve successfully seeded the brains of a number of JSF developers with thoughts of testing with Arquillian.

Of course one can’t mention JavaOne without talking about the Oracle Appreciation Event. Words cannot express how supremely awesome it was to see Pearl Jam perform live! Larry Ellison’s going to have a tough time topping that next year!

All in all, I’d call the event a success. I’ll definitely be submitting a session abstract again next year!

Friday, September 28, 2012

JSF-Testing Session at Java One

I’ll speaking next week at Java One on the topic of “Testing JSF Applications with Arquillian and Selenium. The Session co-ordinates are as follows:

Testing JSF Applications with Arquillian and Selenium
CON7622: Thursday, Oct 4, 2:00 PM – 3:00 PM – Parc 55 – Cyril Magnin I

Unfortunately the Java One website truncated the abstract, and the bit that’s left doesn’t give you a good idea of what I’m talking about. Let’s correct that right away!

We’ll start with a review of Arquillian and Selenium, then look at the Arquillian extensions Drone, Graphene, and Warp and how we can use them to write effective JSF tests. These tools allow us to write “real” tests without the need for mocking the JSF environment, nor running in a crippled client container.

For the sake of completeness, here’s the abstract as originally submitted:


In modern development environments, it’s a “must” to include testing of web applications as a standard part of the development life-cycle. Such tests can also be used as acceptance criteria in enterprise projects. While full-automation is possible, it is considered to be very expensive. As a result, in projects where testing is included as part of the project plan, it is also often the first requirement cut when the project schedule begins to slip.

JSF projects can be particularly difficult to test with basic tools. We’ve seen a revolution with Arquillian that has made integration testing a breeze. Similarly, Selenium helps in UI testing automation. However, neither Arquillian nor Selenium can save the world alone, as their are some outstanding problems that neither of these technologies address:

  • UI test development is slow and decreases developer productivity
  • Client/server co-operation lacks coverage, each is tested independently
  • Selenium tests only: page transitions, JavaScript interaction, and a portion of the DOM
  • The number of Selenium tests can increase quickly, leaving you with maintenance burden

In an effort to reduce the impact of these concerns, we will look at current best practices of how to achieve a rapid turnaround for test development. We’ll also investigate how to take a client-side test to the server and back, verifying state at both ends. Techniques will be shared for minimizing the effort required to write tests, thereby increasing productivity and making your tests future-proof.

Tuesday, August 7, 2012

RichFaces 4.3.0.M1 Release Announcement


The first milestone release of RichFaces 4.3 (4.3.0.M1) is now available. This is a significant release, with primary focus on improving the RichFaces Component Development Kit (CDK) – the tool we use to author our JSF components. A second goal of the release was to improve our MyFaces support, which we accomplished by fixing a number of issues, and identifying some further issues to be addressed in a subsequent 4.3 milestone release.

To try out this release: You can download the distribution directly, or for maven users, increment the RichFaces version in your pom.xml to For more information on setting up a RichFaces 4 application, refer to our getting started guide.

CDK Improvements

RichFaces Component Development Kit (CDK) is a heavy-lifter in the RichFaces Framework. The CDK is the tool we use to author our JSF components. Improvements we make to the CDK improve our ability to deliver components, and will reduce our turnaround on delivering new features for developing web applications.

RichFaces developer Paul Dijou has written up a great summary of the recent CDK improvements. For further details on what has changed, you can refer to the list of individual issues addressed. While the bulk of CDK changes have landed in M1, we will undoubtedly introduce further improvements throughout the rest of the 4.3 release cycle as we push the boundaries on what’s possible with the CDK in our RichFaces Bootstrap sandbox project.

“Real” Tests

Testing of our components and framework has always been a primary concern of the RichFaces project. All our releases to date have been tested not only with unit tests, but also with a large battery of significant number of functional tests. However, functional tests treat the JSF servlet as a black box – we know what we put it and we can test what comes out. On the other hand, unit tests mock the environment where our implementation runs, hiding any issues that would occur only in a real environment. If you think about it, these tests operate in a blind-folded manner: what’s happening as the container executes our application logic?

To this end, the RichFaces project has co-ordinated with the Arquillian project in the development of a new extension: “Arquillian Warp”. With Warp, we can write tests that assert state simultaneously on both the client and the server. For JSF, this means our tests can assert state at arbitrary points throughout the JSF lifecycle. As you can imagine, this opens up a whole new category of tests we can write, as we can not only assert that our application logic has the desired effect, but also that it executes as we expect.

Warp reuses outstanding Arquillian integration with various containers, which allows us to test the integration of RichFaces with many application servers and servlet containers. Furthermore, Warp leverages the Arquillian Drone extension for running Selenium-based tests. Arquillian’s flexibility together with Drone’s ability to drive both real and mocked browsers (ie. HtmlUnit), allows us to run tests using minimal resources in continuous integration, and we can run those same tests in “real” environments to verify integration with many real containers.

Our integration tests makes heavy use of ShrinkWrap to create micro-deployments allowing us to separate the project into small testable pieces. ShrinkWrap Resolvers provides support for resolving various modules from our multi-module project, while ShrinkWrap Descriptors allows us to programatically describe configuration files (like faces-config.xml and web.xml), property files, and Facelet files – which enable us to write tests once and run them in many different configurations.

So far we’ve used this new capability within the framework to harden our RichFaces Push and Resource Mapping implementation, and we will continue to develop new cross-container integration tests of our components and frameworks to complement our already impressive test suite.

Issue highlights

This milestone release addresses a number of bugs as well as new features. For a full list of issues addressed, be sure to check out the Release Notes. However, there are a couple of issues I would like to call out in this blog.

The rich:jQuery function in EL to call a jQuery object from a JSF id as in:

This is a convenience method introduced as a short-hand for the current:

The RichFaces a4j:push feature now has a max inactive timeout, that specifies the maximum amount of time a session is allowed to be inactive. This is an experimental feature, put in place as a workaround while we resolve the underlying issue RF-12219. Try it out, let us know what you think!

Component Upgrades

The RichFaces project is very much an open source project, and leverages other open source projects wherever possible. In this milestone release, we updated the version dependency of some of our upstream projects. These include:

  • RF-12176 – Upgrade to Atmosphere 1.0.0.beta4
  • RF-12334 – Upgrade Mojarra to 2.1.7
  • RF-12335 – Upgrade MyFaces to 2.1.8
  • RF-12336 – Upgrade jQuery to 1.7.2
  • RF-12371 – Upgrade Maven project dependency to 3.0.4

MyFaces Issues

With this release, we’ve also turned our attention to a number of MyFaces issues that we hadn’t addressed with our recent releases. In order to co-ordinate with the JBoss EAP 6 release, we focused predominantly on Mojarra compatibility. However RichFaces is a container agnostic project, and we’re making a concerted effort to improve our MyFaces compatibility with our 4.3 release.

This effort is being facilitated both by the Arquillian Warp project mentioned above, as well as by the TomEE project. TomEE gives us an excellent pre-bundled/pre-configured Tomcat and MyFaces environment against which we can both develop and debug our components – without requiring us to assemble the required jars, and “roll our own appserver”.

As with our CDK improvements, fixing MyFaces issues will continue throughout the 4.3 release. M1 is just a first step in this direction.

What’s Next?

In a recent RichFaces community meeting, we set some goals for the M2 release of RichFaces 4.3. These goals include:

  • Restructure the build (according to the requirements being collected in our wiki)
  • Proceed with further MyFaces fixes
  • Iteration/repeating issues
  • Critical/Popular bugs

Also, be sure to follow the RichFaces Bootstrap project:

In the RichFaces Bootstrap Sandbox project, we are developing our next-generation component set based on top of the Twitter bootstrap project. RichFaces developer Paul Dijou has an excellent write-up on the latest bootstrap updates. Also, check out JSF+LESS blog by RichFaces developer Lukas Fryc, showcasing the real-time CSS/LESS development going on in our Bootstrap project – JSF component styling at it’s best!