Monday, July 21, 2014

RichFaces will pursue a path of stability over innovation


For more than a decade now, JavaServer Faces (JSF) has held a special place as the sole portion of the JavaEE specification that addresses building UI’s for our web applications. As such JSF has historically been the only web front-end we’ve pushed at JBoss. Along with Seam and later CDI, RichFaces has been an important part of our JSF story, and a vehicle for our innovation in the JSF space. We are very proud to see so many of the initiatives we’ve spearheaded in the RichFaces project standardized in recent iterations of the JSF standard.

Nowadays however, developers are increasingly being asked to create mobile web applications; a use case for which the server-side rendering model used by JSF is proving to be insufficient. Many mobile web-developers are looking to client-side javascript frameworks to help them build the rich and fast-responding web applications their users are demanding. Many parts of the industry are moving to rich HTML5-based web apps that leverage frameworks like jQuery or AngularJS with lighter-weight server resources that leverage JAX-RS. Through JBoss Developer ( we’ve been providing examples and quickstarts to help developers explore and get started with these new approaches for building user interfaces. Be sure to take a look through those quickstarts to explore the available alternatives to JSF for building Web UIs.

With these trends in mind, we’ve decided that moving forward we will pursue a path of stability with our JSF approach, rather than a path of innovation. We will continue to track the JSF spec with our RichFaces components and address compatibility issues with new browsers. Applications currently running with RichFaces 4 can continue to do so with an assurance of stability. With this goal in mind we are focusing on delivering a RichFaces 4.5 release, rather than the previously planned RichFaces 5.

RichFaces 4.5 will include:

  • JSF 2.2 compatibility

  • Our replacement Extended PartialViewContext (PVC) that extends the JSF PVC (for better interoperability with other JSF-based frameworks)

  • A re-vamped build consisting of a single (multi-module) repository

  • Chart components developed as part of last year’s GSoC

  • The updated JSF 2.2 compatible RichFaces Fileupload component

  • A type-safe approach for attribute definitions (using interfaces rather than xml)

  • Page fragments for abstracting your functional tests

  • An simplified Asciidoc version of the docs

Some of the ideas we prototyped in RichFaces 5 that will not be available in RichFaces 4.5 include the collapsed component namespace, the JSF independent client-side component implementation (RichWidgets), the Bootstrap theme, and the java package re-factoring.

RichFaces 4.5 will support JSF 2.2 and will be backwards compatible with RichFaces 4.3. This will allow your RichFaces applications to take advantage of the latest and greatest improvements in JSF, without incurring any migration costs. We have a feature-complete release of RichFaces 4.5.0.Alpha3 available today for you to try these features out.

While we are no longer pursuing further innovation with our set of custom JSF components (RichFaces), the JSF runtime on JBoss EAP / WildFly is here to stay - it is part of the JavaEE specification after all. Likewise the JSF tooling in JBoss Tools and Developer Studio will not disappear. You are welcome to continue running your JSF-based applications on JBoss EAP / WildFly using either our stabilized RichFaces components or any of the other JSF component sets available.

Thursday, February 6, 2014

RichFaces 5.0.0.Alpha3 Release Announcement


RichFaces 5.0.0.Alpha3 has been released. With this third alpha release of RichFaces 5 we are providing compatibility with JSF 2.2. Go download WildFly and give the JSF 2.2 capabilities of this release a spin.

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

RichFaces 4 compatibility

We are keeping forward compatibility front of mind with an updated release of RichFaces UI 4.5.0.Alpha2. This release of the RichFaces 4 UI components has been updated to work with the latest RichFaces 5 core.

Release Notes

This release does not provide any new components, but rather focuses on JSF 2.2 compatibility. Looking through the issues resolved you can see both a number of component specific fixes as well as some framework "core" fixes.

Note: While this release adds support for JSF 2.2, you are still free to use RichFaces 5 with JSF 2.1


  • RF-11973 - rich:contextMenu - after ajax re-render of table contextMenu no longer works

  • RF-12813 - rich:panelMenuItem executes action even if disabled attribute evaluates to true

  • RF-12865 - Correct deferred partial response ending by leveraging PVC wrapper chain

  • RF-13040 - Examples don’t work on WildFly

  • RF-13041 - Metamer: demos throw NullPointerException

  • RF-13062 - r:validator stops working

  • RF-13093 - EPVC: ViewState must be written even for transient (stateless) views

  • RF-13168 - 3rd party JSF component disappears on RichFaces ajax refresh

  • RF-13197 - Input with name javax.faces.ViewState is not rendered after submit

  • RF-13198 - ITAutoRegisteredPushServlet fails with - Async is not supported for this request on WildFly80

  • RF-13199 - Framework tests does not include all needed classes to the deployment when deploying on WildFly

  • RF-13208 - Push: error "not well-formed" appears in browser console in Firefox - make messages a valid XML

  • RF-13239 - Popup panel: CSS class rf-pp-hdr contains invalid property repeat-x

  • RF-13252 - a4j:ajax includes jsf.js script twice

  • RF-13317 - ExtendedPartialViewContextImpl should specify correct javax.faces.ViewState id in startUpdate()

  • RF-13358 - rich:panelMenuGroup allowing actions executions even if originally disabled

  • RF-13369 - autocomplete problem in glassfish 4 with jsf 2.2

  • RF-13379 - Build on Travis fails due to NoClassDefFoundEx.: javax/servlet/Servlet (during framework resource optimization)

  • RF-13417 - Some warp-based framework tests fail on WildFly with exception Could not inject members

  • RF-13420 - Showcase - WARNING No mime type could be found for file fontawesome-webfont.woff is logged

  • RF-13444 - r:fileUpload throws IOException "Request prolog cannot be read"

  • RF-13455 - The rich:tabPanel no longer visits tab header facets while rendering a response.

  • RF-13472 - Action listener: binding doesn’t work

  • RF-13496 - StackOverflowError in RendererBase.encodeEnd

  • RF-13498 - Photoalbum - shutting down server with deployed app will throw JdbcSQLException:

  • RF-13508 - Deprecate reslib resource file - RF 4.5/5

  • RF-13513 - CollectionDataModel API is not available on pre-JSF 2.1 that poses backward compatibility problem

  • RF-13518 - Action Listener - invoking from composite component does not work

  • RF-13519 - Stackoverflow in CharRendererBase

  • RF-13520 - mediaOutput: NPE is thrown when used with CDI beans and JSF 2.2

Component Upgrade

  • RF-13432 - Upgrade framework build to JSF 2.2

  • RF-13438 - Update jboss-parent to 12

  • RF-13454 - Upgrade integration tests use of WildFly to 8.0.0.CR1

  • RF-13481 - Upgrade to Warp 1.0.0.Alpha6


  • RF-13278 - Add support for a header meta-component to the rich:tabPanel

  • RF-13307 - Support java.util.Collection in iteration components

  • RF-13314 - Deprecate reslib resource files

  • RF-13494 - Make the RichFaces RendererBase decode/encode* methods final


  • RF-13248 - Switch RichFaces smoke tests to run on WildFly 8 by default

  • RF-13343 - Page Fragments: Re-implement setupFragmentFromWidget() methods using component options access

  • RF-13448 - Add javadoc to the SequenceIterationStatus class

  • RF-13517 - Mark all framework tests that requires JSF 2.2 with a new @Category(RequiresJSF22)

Next steps

We have begun work on RichFaces 5.0.0.Alpha4. Our fourth alpha release will provide some additional component migrations to the new RichWidget-based architecture and the associated Bootstrap-based style.

Wednesday, December 11, 2013

RichFaces 5.0.0.Alpha2 Release Announcement


RichFaces 5.0.0.Alpha2 is now available for download. This second alpha release of our RichFaces 5 effort is significant as it brings in our new component architecture, new components, a further refinement in our approach to testing, and the beginnings of a new look and feel. We’ll dive further into each of these topics below.

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

New Component Architecture

We’ve been planning a new component architecture for quite some time. We PoC’ed the concept last year, and we now have the groundwork in place to move full-steam ahead.

Our new component architecture is based on standalone javascript widgets loosely coupled to the JSF back-end via an event-based mechanism. Building JSF components on top of standalone javascript widgets has (among others) the following benefits:

  1. Reduced delivery-time on new components when re-using existing OSS widgets.

  2. Improved testability when testing widgets across many browser implementations/versions.

  3. Widget re-use across multiple web frameworks - allowing for poly-framework/polyglot web applications with a consistent L&F.

After delivering RichFaces 5.0.0.Alpha1 we went off and hid in a corner for a while to lay the foundation for the javascript work required to pull this off. We wanted to create a space where we could contribute our javascript development efforts in a true OSS manner and participate as closely as possible with upstream projects.

To this end we created RichWidgets, a pure javascript project that sits upstream of RichFaces, providing the javascript implementations of the RichFaces 5 set of components. Built with grunt and bower, and tested with karma and jasmine, the project should be easily accessible to all participating in the javascript development space, irrespective of the server-side framework/language with which they are trying to inter-operate.

Styled with Bootstrap and the Red Hat Common User Experience, and powered using the jQuery UI widget factory, RichWidgets provides users with both a consistent API and a consistent look-and-feel.

Checkout what we have so far by browsing the RichWidgets demo site, of by taking a look at the source code on GitHub. If you are still curious, learn more about RichWidgets in the RichWidgets 0.1 release announcement.

New Components


The RichFaces 5 chart component was built by a GSoC student (Lukas Macko) using the above mentioned JSF component architecture. Built using the Flot charting library, the flot charts were first wrapped as RichWidgets to provide a consistent javascript API and L&F. Check out the RichWidgets demo of the charts widget.

The RichWidget charts were consumed by RichFaces, providing a first-class JSF component. The RichFaces chart component demo is currently shown in our old RichFaces 4 showcase - we are hard at work creating a new showcase specific to RichFaces 5.


The RichFaces autocomplete component has had a client-side rewrite using the RichWidgets approach. Starting with the jQuery UI autocomplete component, the RichWidget autocomplete widget was built-up to have the features and extension points required for RichFaces integration. The resulting RichWidget autocomplete widget demo shows well the capabilities of the autocomplete widget.

The RichWidget autocomplete widget was wrapped using the RichFaces CDK to provide another first-class JSF component. The JSF facelet API has been maintained wherever possible to make it easy to migrate to the new version of the component. You can see the RichFaces autocomplete component demo in the richfaces-latest showcase.


In a similar manner to the r:autocomplete rewrite, the r:orderingList we re-implemented as a javascript widget, built on top of the jQuery UI sortable and selectable plug-ins. The RichWidget orderingList widget demo shows the new capabilities achieved with this widget rewrite, including support for dragging items to re-order them.

RichFaces 5 is consuming the orderingList widget via the RichFaces CDK, bringing these new capabilities to RichFaces/JSF applications. Visit the RichFaces orderingList component demo to see these capabilities in action.


The fourth and final new component available with RichFaces is the pickList component. Composed using two orderingList RichWidgets, the pickList also provides drag-and-drop between the source and target lists. Check out the RichWidgets demo of the pickList widget, and the RichFaces demo of the pickList component.


While not a new component, the fileUpload component has received a new "multi-file upload" feature thanks to a git pull request from Anthony O.. This addition to the r:fileUpload component allows a user to select multiple files at one time for uploading. Availble in RichFaces 5.0.0.Alpha2 and RichFaces UI 4.5.0.Alpha1.

Migrating applications

With a revision in the major version number, I know many of you are apprehensive about the overhead involved in migrating to Richfaces 5. We have taken your concerns to heart, and have worked heavily on porting the RichFaces 4 components to work the with the re-vamped RichFaces 5 core as a separate jar. We are releasing this as Richfaces UI 4.5.0.Alpha1. With this component set, you will be able to re-use the RichFaces 4 components in your Richfaces 5 application without any changes required to your facelet code. You can then migrate to the new RichFaces 5 components on an as needed basis.

To enable this feature, we’ve changed the RichFaces 5 facelet namespace to be non-conflicitng. If you have been using RichFaces 5.0.0.Alpha1, you’ll have to change your namespace.

As of RichFaces 5.0.0.Alpha2, the facelt namespace for components is:


In a parallel effort, we are working to maintain the facelet API of the RichFaces 5 components to minimize any barrier to adoption of the new components. We are tracking any such API changes that we do make, and will make these notes available in our 5.0.0.Final release documentation.

Testing Components with Page Fragments

The RichFaces QE team has developed a set of Arquillian Graphene Page Fragments for use in testing our components. The neat thing about page fragments, is they componentize the testing model, allowing for easy code re-use. What do this mean for you as a RichFaces developer? You can use the RichFaces page fragments to test your own application, and write your tests to a high-level component API, without worrying about the underlying DOM implementation. If we update the DOM implementation of a component in a future release, we’ll update the page fragment with it. Your tests will not have to change to reflect the DOM change in any way!

This idea is truly revolutionary, and I look forward to see how you the RichFaces community adopt these page fragments, and where you will take them. Functional testing of enterprise web applications has never been so compelling!

Next Steps

You will likely have noticed the lack of a mention of JSF 2.2 in this release announcement. Unfortunately our plate was too full with this release to properly tackle JSF 2.2 support. We do however recognize this as important to many of you, particularly with WildFly 8 in a Beta stage. With this in mind we will make JSF 2.2 our primary focus for RichFaces 5.0.0.Alpha3, and will work to expedite its release. We will also continue with a release of our stable RichFaces 4.3 branch in the new year.

Friday, June 14, 2013

RichFaces 5.0.0.Alpha1 Release Announcement


I am excited to announce the release of RichFaces 5.0.0.Alpha1. While RichFaces 5.0.0.Alpha1 is an incredibly significant release (with almost all aspects of the framework seeing some changes) the release is in fact functionally equivalent to RichFaces 4.3.2.Final. So go ahead an try it out, and give us your feedback!

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

Release highlights

The primary goals for RichFaces 5.0.0.Alpha1 were as follows:

Read a summary of each of these changes below, with links to blogs containing additional details.

Re-structure the build

The original design goal of the RichFaces 4 build was to enable partial builds of the framework to reduce the developer turnaround time in developing new components. While this breaking apart of the build into pieces was an attractive idea on paper, it didn’t work out that well in practice. The cost of assembling the partial build artifacts into the distributed framework was too high, and the various partial builds turned out to be more inter-dependent than expected.

With the 4.3.0.Final release of the RichFaces CDK we introduced an incremental build feature that removed the need for these partial builds. With this incremental build we could now build the framework in a piecewise manner, without requiring the framework to be segmented into partial builds. This led us to re-engineer the build based on current requirements and use cases, and was one of the primary motivating factors for RichFaces 5.

The end result is a build structure now contained within a single repository that is easier for both newcomers and seasoned RichFaces developers to grok. We hope this will encourage more community members to dive into the source code and contribute to the success of the framework. Should you still need to work with the RichFaces 4 source, it is available in the separate RichFaces 4 GitHub "organization"

Blog Read more about the motivation and implementation of the new build in the RichFaces Build Re-Structure blog post.

Collapse the rich: and a4j: namespaces

As you may know, the current RichFaces framework is built from the old Ajax4Jsf project, and the original RichFaces component set. This distinction of the libraries has been preserved in the RichFaces framework with the use of the rich: and a4j: namespaces. However this distinction has blurred over time, and has unfortunately become a barrier to adoption for new RichFaces users.

In RichFaces 5, starting with this Alpha1 release, we are collapsing the namespaces into the single r: namespace. This will ease adoption for new developers, and allow for a more intuitive tooling experience within your IDE.

Blog Read more about the namespace change, and how to automate the migration of your own applications to use the the new namespace in the Namespace section of the Build Re-Structure blog.

The RichFaces 5 Showcase has been updated to reflect the simplified showcase.

Framework distribution simplification

Incorporating RichFaces into your applications is easier with RichFaces 5. We now distribute a single richfaces.jar. No more separate API/UI/Impl jars, and no more BOM! If you are using maven, simply add the RichFaces jar to your project as in:


Improvements to testing

Testing has always been a primary concern of the RichFaces project. In RichFaces 5 we have taken our testing efforts to the next level with the incorporation of the Arquillian Graphene and Arquillian Warp extensions.

Blog Read how RichFaces uses these tools to provide real, automated and fast tests for our framework.

Blog Read how you can use these tools yourself to test your JSF applications with this blog series on testing JSF.

Move to asciidoc for our documentation

Last but not least I’ll mention the improvements we’ve made to our documentation workflow. Docs for RichFaces have always been a big part of the project. However we recently started to notice we had a large barrier for doc contributions that were anything more substantial than minor edits and small additions. This was due to the manual/direct editing of the Docbook XML source. XML is simply not conducive to an efficient authorship workflow.

In RichFaces 5.0.0.Alpha1 we have incorporated AsciiDoc into the top of our existing Docbook tool-chain. This has dramatically improved our documentation contribution workflow without compromising any flexibility nor expressibility. The RichFaces 5 docs are already quite more accessible than the RichFaces 4 ones, and we’ve only just begun to re-vamp the content.

Blog Read more about our move to AsciiDoc in this blog post RichFaces moves to AsciiDoc.

Next Steps

With these high-impact (yet mundane) changes behind us, we are excited to move forward with RichFaces 5 development. We’ve already started laying out our RichFaces 5.0.0.Alpha2 sprints as we execute on our RichFaces 5 Road Map. Next up is LESS/Bootstrap integration, and incorporation of our standalone javascript widgets.