Friday, April 11, 2014

RichFaces Security Advisory CVE-2014-0335


A security vulnerability has been uncovered and resolved in RichFaces 4. Details of the vulnerability can be found in this Red Hat Errata document released for our WFK product. We have released a community micro release addressing this vulnerability, so please update your applications ASAP. Read below for a summary of the problem and some additional minor fixes included in this release.

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

The issue

The issue was reported and resolved through community efforts in RF-13250. Much thanks to Marcel Šebek for both investigating and patching this issue!

The vulnerability

The vulnerability manifests itself when malformed Atmosphere requests cause RichFaces to leak memory. This memory leak can be exploited via a large number of requests to a push-enabled RichFaces application leading to an out-of-memory error, and a corresponding DDoS on the underlying application server.

This 4.3.6.Final release of RichFaces no longer leaks memory leak when receiving malformed Atmosphere requests. Users are encouraged to update their deployed RichFaces applications, particularly those that are push-enabled.

Note: while we have included the patch in RichFaces 5, we have not shipped an update to the RichFaces 5.0.0.Alpha3 release. The fix will be present in an upcoming 5.0.0.Alpha4 release.

Other fixes

Check out the 4.3.6.Final release notes for a complete list of issues resolved in this release. The issues for the most part are stabilizations to our Photoalbum demo. However some noteworthy issues include:

  • RF-13531: selects: cannot select option on IE11

  • RF-13559: a4j:commandButton wrong actions performed

  • RF-13540: Websphere incarnation of MyFaces renders optimized resources multiple times

Next Steps

We are hard at work putting out a RichFaces 4.5 release to address JSF 2.2 compatibility with the RichFaces 4.x branch. This has necessitated we put RichFaces 5 development on hold, but we feel will be worth it to get JSF 2.2 support in a stable release sooner rather than later.

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.

Tuesday, February 4, 2014

Presentation Tier Technology Survey

It’s feedback time! Developers today are presented with an abundance of options when selecting which technologies will form the basis of their applications. Even if we constrain ourselves to the presentation tier, that choices available are staggering. Technology providers then get to play the fun game of anticipating in which direction its users and customers are headed and make sure they are providing them with value.

To help us at JBoss better understand in which direction you are headed with your applications of today and tomorrow, we have prepared a quick 3-question survey on Presentation Tier technologies. Your taking the time to fill out this survey will help us tremendously in getting a better understanding of this problem, and help us make sure we are providing you the tools and capabilities you are looking for in building and delivering your applications.


Please fill out this quick 3-question survey to help us at JBoss better understand the presentation tier technologies you use when building your applications.

Monday, January 27, 2014

RichFaces 4.3.5.Final Release Announcement


We are happy to release an update to our stable branch with the release of RichFaces 4.3.5.Final. This 5th micro release of the RichFaces 4.3 release series provides a number of bug fixes while we concurrently work on RichFaces 5.

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

Release Highlights

This release resolves 50 issues, making RichFaces 4.3.5 a substantial bug-fix release. The issues themselves span a number of components and features, offering an overall increase in framework stability.

With this release we have brought back the Photoalbum demo from the RichFaces 3 project. We’ve enhanced the demo offering social media tie-ins to facebook and google plus. Check out the source code on github.


  • RF-11469 - autocomplete method does not resolve bean if ui:included and only one parameter provided

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

  • RF-12811 - VDL Documentation: rich:calendar is missing attribute "maxlength"

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

  • RF-13172 - rich:toolbarGroup location="right" doesn’t work if toolbarGroup location="left" contains not rendered values

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

  • RF-13220 - Quickstart - Remove references to AS 7.1 in the RichFaces quickstarts

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

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

  • RF-13257 - PhotoAlbum: uploading and deleting images

  • RF-13266 - mediaOutput not working anymore on Glassfish3 and EAP6.1

  • RF-13287 - rich:extendedDataTable column resizing with ajax loading not working properly

  • RF-13292 - Autocomplete: up and down arrow keys not working in Opera

  • RF-13298 - Richfaces BOM manages a non Maven Central dependency

  • RF-13342 - archetype-simpleapp: facelet with name title is not defined in template, but it is used in the sample

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

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

  • RF-13464 - Photoalbum: bad positioning of progressBar for G+/FB login on Firefox

  • RF-13465 - Photoalbum: cannot run album slideshow when an image has been added

  • RF-13466 - Photoalbum: editor for creating comments has not visible toolbar

  • RF-13467 - Photoalbum: wrong selector in js function when selecting album from multiple album groups

  • RF-13468 - Photoalbum build fails with JDK 6

  • RF-13471 - Photoalbum: search: option for search in own albums is not visible when logged in

  • RF-13473 - Photoalbum: cannot open help for fileUpload and dataScroller

  • RF-13485 - Photoalbum: cannot login with FB account

  • RF-13486 - Photoalbum: viewing g+ albums improvements

  • RF-13487 - Photoalbum: viewing FB albums improvements

  • RF-13497 - Photoalbum: cannot add album via contextMenu

  • RF-13500 - Photoalbum: viewing Facebook albums throws exception

  • RF-13501 - PhotoAlbum: sharing a photo does not work, can not choose album

  • RF-13502 - Photoalbum: editing uploaded photo throws NPE

Component Upgrade

  • RF-13277 - Upgrade Atmosphere to 1.0.18

  • RF-13310 - Upgrade Graphene and Warp in 4.3 branch Enhancement

  • RF-13274 - Use QSTools:archetypeSync to keep the kitchensink archetype synchronized with the kithensink-rf quickstart

  • RF-13314 - Deprecate reslib resource files

  • RF-13439 - Photoalbum - update help section

  • RF-13462 - Photoalbum: improvements for adding album and album groups

  • RF-13463 - Photoalbum: improvements for adding images

  • RF-13479 - Re-organize files/folders in the top-level webapp folder

  • RF-13480 - Java package re-structure for the photoalbum demo


  • RF-13047 - Implement improvements to the photoalbum application

Feature Request

  • RF-12793 - Photoalbum improvements

  • RF-12949 - Create a set of Photoalbum smoke tests which will verify it starts and that the basic features works

  • RF-13227 - Prepare the RichFaces 4.3.x photoalbum for release

  • RF-13305 - Autocomplete: i must press button twice for popup window

  • RF-13306 - Autocomplete: initialize value from DOM (was: ignored API call .setValue(''))


  • RF-13268 - Typo in Task

  • RF-13404 - Port the RichFaces 5 improvements back to RichFaces 4.3

  • RF-13405 - Merge the photoalbum fixes from QE

  • RF-13509 - Add Photoalbum sources to RichFaces distribution

Moving forward

You will likely have noticed no mention of JSF 2.2 in this announcement. We are not at this time introducing JSF 2.2 support into our stable branch, but are rather doing so in the upcoming 5.0.0.Alpha3 release of RichFaces. Progress on RichFaces 5 has continued while we prepared the 4.3.5 release, and we have already committed a number of JSF 2.2 related fixes. Look for this release in the next week or two.

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.

Tuesday, September 17, 2013

RichFaces 4.3.4.Final Release Announcement


I am excited to announce the release of RichFaces 4.3.4.Final. This 4th minor release of the RichFaces 4.3 release series is conservative in scope focusing on providing bug fixes to our stable release branch while we concurrently work on RichFaces 5.

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

Release Highlights

With 47 issues resolved, RichFaces 4.3.4 is a substantial bug-fix release, offering improvements in a number of components including the select components, extendedDataTable, popup panels, and a4j:log.

Additionally we upgraded our Atmosphere dependency to the latest release (1.0.17) to ensure RichFaces Push continues to work with the upcoming JBoss EAP 6.1.1 release. A big shout out to @jfarcand and his Atmosphere community for accepting our pull request and getting an updated release out in a timely manner. Working with Atmosphere as an upstream project is truly an example of OSS at it’s best!


  • RF-11275 - showcase - rich:popup - Sample Modal panel - after changing the size of popup there is double shadow

  • RF-11691 - [rich:select] value disappears if you click between list and value

  • RF-12345 - JS error when pressing ESC on an open inplaceSelect in IE

  • RF-12853 - rich:inplaceSelect: JS API bugs

  • RF-12929 - PickList change event not firing correctly when ordering objects in target area

  • RF-12943 - ExtendedDataTable: clearing of filter input doesnt work correctly

  • RF-12989 - Documentation for togglePanelItem is wrong and 4.2.2 components are not working anymore in 4.3.0.Final

  • RF-13010 - Popup panel inside popup panel: button not rendered in IE10

  • RF-13017 - richfaces-bom 4.3.2.Final, JSF-API 2.1.0 not compatible

  • RF-13035 - Simpleapp Archetype: mobile version shows modal dialog

  • RF-13046 - EDT in EDT: when @frozenColumns is equal to number of columns then there is no vertical scroller in EDT

  • RF-13053 - Showcase: push doesn’t work on EAP 6.1

  • RF-13057 - Kitchensink Archetype: update enterprise version of JBoss BOM

  • RF-13058 - Kitchensink Archetype: JSF community site link doesn’t work

  • RF-13059 - Richfaces quickstart README files contain links that to be updated

  • RF-13060 - Issue in initializing the list of selected items in a Picklist

  • RF-13086 - Popup panel: button’s label is invisible in IE8

  • RF-13094 - Wrong extendedDataTable header widths when narrowing columns

  • RF-13098 - Regression: mediaOutput broken for CDI MediaData beans

  • RF-13102 - rich:calendar with date pattern- input gets cleared on click

  • RF-13106 - Quickstart names in the POM files are not consistent and often are not clear

  • RF-13107 - ajaxRenderer component are renderer even though they are in non-active switchable panel, causing JSF to fail to update DOM

  • RF-13117 - ExtendedDataTable Sorting resets $(window).resize Events

  • RF-13119 - kitchensink-rf test-ds.xml does not use a unique datasource JNDI name

  • RF-13125 - a4j:log swallows the message from jsf.js’s sendError method

  • RF-13133 - ExtendedDataTable: filterType=custom doesn’t work when mixing custom and built-in filter columns

  • RF-13136 - a4j:log with mode=console doesn’t take log level into consideration

  • RF-13137 - a4j:log - wrong log levels in attribute description

  • RF-13140 - PopupPanel: Hide @visualOptions and @keepVisualState options which weren’t implemented yet

  • RF-13142 - Showcase: mediaOutput sample is not working with MyFaces

  • RF-13149 - a4j:push in Metamer doesn’t have subtopic name

  • RF-13161 - rich:notifyMessages CSS incorrect on MyFaces 2.x

  • RF-13174 - Correct the WFK version of the JBoss BOM used in the archetypes

  • RF-13195 - Showcase: Unauthorized deserialization attempt with MyFaces

  • RF-13205 - Photoalbum: Hibernate error during deployment

Component Upgrade

  • RF-13132 - Upgrade JBoss Java EE BOMs to 3.0.2.Final

  • RF-13154 - Upgrade Atmosphere to 1.0.17 (a4j:push fails with CNFE for org.apache.coyote.http11.upgrade.UpgradeInbound on latest EAP 6) Enhancement

  • RF-12784 - Showcase readme - update deployment from eclipse part

  • RF-13097 - showcase: update readme with password for jbas7 profile

  • RF-13150 - Remove JMS functionality from the RichFaces showcase

  • RF-13153 - Update version.compiler.plugin and jboss.maven.plugin versions in the quickstart POM files

  • RF-13169 - Replace hardcoded version in Arquilian FundamentalTestConfiguration with project version property - from pom file

Feature Request

  • RF-13038 - Command button/link: attribute tabindex missing

  • RF-13063 - RichFacesInputNumberSlider setValueByDragging

  • RF-13159 - Add Maven compiler properties and remove Maven plugin from the the quickstart POM files

  • RF-13185 - Quickstarts: Modify GAV to use org.jboss.quickstarts.rf


  • RF-13189 - Update jquery-atmosphere.js to 1.0.17 in 4.3.x

Moving forward

We are actively working on RichFaces 5.0.0.Alpha2 that will feature some re-worked components taking advantage of our new decoupled component architecture and making use of standalone javascript widgets to provide a more robust client-side implementation of RichFaces components. Look forward this a new Alpha release in the coming weeks.

Tuesday, July 16, 2013

RichFaces Security Advisory CVE-2013-2165


We have fixed a security vulnerability in RichFaces 3, 4 and 5. Details of the vulnerability can be found in this Red Hat Errata document released for our WFK product. We have released community micro releases addressing this vulnerability, so please update your applications ASAP. Read below for a summary of the problem and an explanation of how to use the fix in your applications.

Download RichFaces 3.3.4.Final or RichFaces 4.3.3.Final and use them in your applications to protect yourself from this vulnerability.

The vulnerability

The vulnerability consists of using RichFaces resource deserialisation to trigger the deserialisation methods of any class deployed in the server. The extent of the vulnerability is limited by the classes available, but could potentially let the attacker cause a denial-of-service condition or — in extreme cases — to inject arbitrary code [1].

The fix

The fix involved creating a whitelist of classes that are available to participate in the RichFaces resource deserialisation process. Details of the implementation of the fix are well described in this article on Look-ahead Java deserialization in the IBM developerworks.

The whitelist that ships with RichFaces 3, 4, 5 consist of the classes for the primitive tpyes, as well as classes that implement the following interfaces:

  • RichFaces 3

    • org.ajax4jsf.resource.InternetResource

    • org.ajax4jsf.resource.SerializableResource

    • javax.el.Expression

    • javax.faces.el.MethodBinding

    • javax.faces.component.StateHolderSaver

    • java.awt.Color

  • RichFaces 4, or RichFaces 5

    • javax.faces.application.Resource

    • javax.el.Expression

    • org.richfaces.resource.SerializableResource

    • javax.faces.component.StateHolderSaver

Notice the SerializableResource interface - this is an interface you can implement in your classes to allow them to participate in Richfaces resource deserialisation. This however is not something you will have to do unless you have gotten into some serious resource customisation.

Alternatively, you can copy the file into your own application (using the same package) and add additional interface/class names to the whitelist. This will enable you to have your classes participate in the deserialisation process without needing to compile.

Note: while we have included the patch in RichFaces 5, we have not shipped an update to the RichFaces 5.0.0.Alpha1 release. The fix will be present in an upciming 5.0.0.Alpha2 release.

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.

Monday, June 10, 2013

RichFaces moves to AsciiDoc


With RichFaces 5 we have made a significant change to our documentation tool-chain with the introduction of AsciiDoc to simplify the task of authoring and editing the RichFaces documentation. Our documentation has for a long time been based on Docbook xml against which we have applied the Red Hat PressGang XSLT to create the HTML and PDF output of our docs.

Additionally the Docbook xml is fed downstream into Red Hat’s Web Framework Kit product (WFK), where it undergoes further transformations to fit well into Red Hat’s product documentation. Docbook xml is great for such manipulations, but it is by no means straight-forward to author. Anything more than simple edits quickly turns into a complex task.

Bring in the AsciiDoc!

Fortunately we have been able to remedy this problem, without sacrificing any of the power and flexibility of our Docbook tool-chain, by converting all our Docbook source into AsciiDoc. The AsciiDoc source is in turn converted back into Docbook xml, and fed into our existing tool-chain. This toolchain is a set of Pressgang XSLT files that takes the Docbook xml and converts it into our published PDF and HTML docs.

The capabilities of AsciiDoc are well demonstrated by the fact that we were able to create identical HTML and PDF docs using the AsciiDoc generated Docbook xml, without making any changes to our Docbook tool-chain. AsciiDoc is indeed a highly expressive markup language. On the other hand, AsciiDoc is only as complex as you want it to be - in basic use cases it’s as simple to read as Markdown.

The one-time conversion to AsciiDoc

Converting the Docbook xml into AsciiDoc however was not a simple task. We had a significant step forward by starting with the docbook2asciidoc XSLT project from O’Reilly media that converts Docbook xml into AsciiDoc. Jason Porter had already forked the project, introducing some changes to handle Red Hat flavoured Docbook.

We forked that fork, and introduced a number of additional changes to the XSLT to properly convert the Docbook xml into AsciiDoc. This conversion took us 98% of the way there, the final leg of the conversion was finished with some regexps and manual fine-tuning.

We also looked at the Pandoc project - a multi-purpose document converter that is able to output Docbook xml. We stuck with the XSLT for two reasons:

  1. Out-of-the-box the XSLT brought us closer to our target.

  2. Our XSLT expertise allowed us to hack the docbook2asciidoc to suit our needs, wheres Pandoc is written in Haskell which presented too a steep learning curve for a one off migration.

Although had our initial format not been xml, Pandoc would probably have been a better choice. Hopefully the Asciidoctor project is able to fill this conversion-to-asciidoc void in a future release.

Checkout the results, here are links to the AsciiDoc files on GitHub. Notice how GitHub renders the files, you can click the "raw" buttons to see the AsciiDoc source.

RichFaces Component reference


RichFaces Developer Guide



A word on AsciiDoc implementations. AsciiDoc is by no means a new kid on the block - the original python implementation has been around since 2002. However in 2012 a second implementation of AsciiDoc was begun called Asciidoctor. Written in Ruby, Asciidoctor has recently caught up with the original AsciiDoc implementation, and in many ways surpassed it. Asciidoctor is amazingly fast, rendering documents an order of magnitude more quickly than the original python implementation.

Coupled with these general improvements, the Asciidoctor community has done a great job integrating the ruby-based Asciidoctor with java via the asciidoctor-java-integration project. This java integration is then used to create a full-featured asciidoctor-maven-plugin, making Asciidoctor a natural choice and a good fit into our existing tool-chain.

Changes with RichFaces 5

Following the AsciiDoc conversion, we put the new format to the test with a massive edit of the docs to reflect the changes we introduced to the framework in RichFaces 5. I’m happy to report that the transformation was a success - the doc changes were nearly trivial to implement. This is indeed a huge step forward for the project, and will enable us to provide you, our user community, with much better documentation.

Enable the community!

Conversely, we are hoping the more accessible format will enable more of you to jump in and fix errors and provide additions as you notice gaps in the documentation. So jump in! Give the new docs a read, and click that edit button in GitHub to initiate a pull request with any improvements you can suggest!

Next steps

While we will release RichFaces 5.0.0.Alpha1 with our new AsciiDoc based documentation, we are by no means down with our doc changes. Now that we have the new simpler AsciiDoc source in place, we will re-arrange the docs to provide something that is both more accessible and useful.

Thursday, May 16, 2013

RichFaces 4.3.2.Final Release Announcement


I am excited to announce the release of RichFaces 4.3.2.Final. - This 2nd minor release of the RichFaces 4.3 release series provides a number of bug fixes further increasing the stability of the framework.

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

Release Highlights

This release of the RichFaces framework is not accompanied by a release of the CDK. The 4.3.2.Final release of RichFaces was created with the 4.3.1.Final version of the RichFaces CDK. Future RichFaces 4 releases will only be accompanied by a RichFaces CDK release when a CDK fix was required to enable the framework release.

With fixes to the extendedDataTable, tab panel, autocomplete, fileuplaod and popup panel, as well as some fixes addressing compatibility with the latest Mojarra release, you’ll definitely want to move your applications to this release and take advantage of these improvements. Refer to the release notes below for a complete listing of what has been fixed in this release.


  • RF-12193 - rich:extendedDataTable is blank on show

  • RF-12765 - Rich:tabPanel not possible to switch tabs when only dynamic tabs are present

  • RF-12812 - Autocomplete does not hide popup on tabbing to the next field

  • RF-12827 - Showcase - switching among dynamically created panels, tabs cease to function

  • RF-12839 - Toggle panels: ajax-related attributes do not work

  • RF-12846 - a4j:commandLink accesskey attribute missing

  • RF-12847 - Fix quickstart license and white space issues exposed by qstool report

  • RF-12848 - Error "source is not defined" after richfaces-jsf-event.js merge

  • RF-12850 - Popup panel: button's label is invisible in IE10

  • RF-12851 - The RichFaces kitchensink-rf quickstart/archetype incorrectly depend on the AS google guava module

  • RF-12858 - rich:calendar dateselect event is fired twice

  • RF-12868 - Update the Summary of the RichFaces kitchensink quickstart

  • RF-12893 - Partial response not ended correctly on exception

  • RF-12928 - ExtendedDataTable: columnsOrder doesnt work after changing order

  • RF-12931 - rich:fileupload broken with jsf.js changes in Mojarra 2.1.21

  • RF-12933 - rich:tooltip replace 'defaultContent' facet in docs and examples with 'loading'

  • RF-12958 - Popup panel opened from inside popup panel doesn't work

  • RF-12969 - rich:tabPanel: Click on already selected rich:tab causes JavaScript error

  • RF-12975 - rich:extendedDataTable - can not change order of columns

Component Upgrade

  • RF-12688 - Upgrade Guava from 11.02 to 13.0.1

  • RF-12780 - Upgrade to Mojarra 2.1.19

  • RF-12898 - Tie RichFaces 4.3 to CDK 4.3.1.Final


  • RF-12784 - Showcase readme - update deployment from eclipse part

  • RF-12786 - Showcase - rewrite readme to markdown

  • RF-12964 - Create appropriate push timeouts for the showcase

Feature Request

  • RF-12810 - Introduce profiles for verification of fundamental tests on Tomcat 6 and 7, TomEE 1.5 and GlassFish 3.1

  • RF-12849 - Showcase - update readme - remove obsolete, add new

  • RF-12935 - Fix resolution of framework tests' artifacts with version enforced

  • RF-12937 - Introduce a profile for running framework tests against JBoss EAP

  • RF-12938 - Update Shrinkwrap

  • RF-12940 - Showcase: fix path to outputPanel - compositeMessages sample source

  • RF-12941 - Showcase: ProgressBar demo - remove obsolete attribute and make the progress smoother


  • RF-12843 - Apply unix style line-endings to the entire codebase

Moving forward

We’ve finished development of RichFaces - 5.0.0.Alpha1, and our QA team is currently working on stabilizing for a release. So stay tuned for an exciting announcement of the availability of our first RichFaces 5 Alpha!