This document is aimed to provide guidelines for migrating RichFaces projects from 3.1.x versions to 3.2.0.
RichFaces Migration Guide implies descriptions concerning issues caused by migration and provides suitable workarounds and examples.
This document should not be used as a tutorial for RichFaces framework since it is created to describe the issues caused by migration process
It is assumed that you are familiar with basic tenets of RichFaces framework. If you are newbie in RichFaces you can find RichFaces documentation here.
Concepts related to Web or application servers configuration, JSF, JSF implementations are beyond the scope of this document
You can find all technical requirements to start working with RichFaces 3.2.0 in the Developer Guide.
This chapter includes only the issue with migration from previous versions to 3.2.0. Issues with new components and other problems are not included. The Jira contains everything.
Application with i18n does not work correctly caused by the validation error when non-ASCII characters is used
...
<select id="j_id27:cbxUser" name="j_id27:cbxUser" size="1" style="width:120px">
<option value="Al Korbeli& #269;o">Al Korbeli& #269;o</option>
<option value="Al Nagyov& aacute;">Al Nagyov& aacute;</option>
<option value="Al Tothov& aacute;">Al Tothov& aacute;</option>
<option value="An Gajdov& aacute;">An Gajdov& aacute;</option>
...
</select>
...
The decision is to upgrade to RichFaces 3.2.0 SP1
Menu components are not working with JSF-RI-1.2_08:
The <rich:contextMenu> component is not invoked by the right mouse click
The <rich:dropDownMenu> component causes the exception with showing XHTML invalid output
Downgrade to JSF-RI 1.2_07 or use recent JSF-RI SNAPSHOT.
Binding does not work for all components in JSP. It is impossible to use "binding" attribute for RichFaces components. Wrong class-name is used in TLD generated from XML configuration files.
There was <classname>java.lang.String</classname>
instead of <classname>javax.faces.component.UIComponent</classname>
in configuration files.
The decision is to use Facelets upgrade to RichFaces 3.2.0 SP1
Ajax requests stop to work without any errors shown when intensive Ajax traffic is expected. No error or other diagnostic presents.
Do not define an id for Ajax command component.
...
<h:form>
<h:panelGrid columns="2">
<h:inputText id="myinput" value="#{userBean.name}">
<a4j:support event="onkeyup" reRender="outtext" />
</h:inputText>
<h:outputText id="outtext" value="#{userBean.name}" />
</h:panelGrid>
</h:form>
...
This is a specific of the dynamic id generation of the JSF 1.2 implementation. In case of simultaneous request processing, the id of the command component becomes out-of-sync with id of the same component on the page. After that any Ajax requests from the component with old id just do not process.
When standard skinning classes or background images are inaccessible "Resource not registered : org.richfaces.renderkit.html.images.InputBackgroundImage" (another name is possible) exception appears in server log.
Resources for standard skinning classes haven't been registered during RichFaces library build
Switch off standard skinning classes by setting initial parameter in web.xml:
...
<context-param>
<param-name>org.richfaces.CONTROL_SKINNING_CLASSES</param-name>
<param-value>disable</param-value>
</context-param>
...
Add META-INF/resources-config.xml to the application classpath.
The <rich:calendar> date selected event is fired before input update.
After time and apply elements have been added to calendar "ondateselected" gets fired after date selected but before updated in input. Now we have three events instead of one. But it causes compatibility problem because this event was used by customers to save selected value via Ajax.
Put <a4j:support> inside <rich:calendar>. If the "event" property is "ondateselected" previous value of the <rich:calendar> is stored after selection.
Two <rich:datascroller> components bound to the same table aren't synchronized. Storing data component in session-scoped beans no more saves <rich:datascroller> state. It is a common pattern to have 2 <rich:datascroller> components: the first in header, the second in footer. The first will not work.
The <rich:datascroller> component is now responsible for managing data table's scroll state.
The <rich:datascroller> component's "for" attribute doesn't allow EL expressions in 3.2.0.GA.
Custom tags exploiting the ability of the <rich:datascroller> to have dynamic "for" attribute doesn't work.
Just add the following code, that will not work:
...
<rich:datascroller for="#{bean.property}"/>
...
Please, see Jira
The RichFaces components that have "ajaxSingle" = "true" will not work in "header" or "footer" facets of <h:dataTable>, e.g. <rich:datascroller> won't scroll.
Just add the following code. The <rich:datascroller> component will not work:
...
<h:dataTable>
<f:facet name="header">
<rich:datascroller ajaxSingle="true"/>
</f:facet>
...
</h:dataTable>
...
The ajaxSingle/region requires invokeOnComponent()
to work properly. For more details, please,
see JavaServer Faces issues reporting page.
The "fileUploadListener"(UploadEvent event) is not invoked when MyFaces or JSF-RI 1.2_04 is used. But file is uploaded successfully.
In case MyFaces org.apache.myfaces.CHECK_EXTENSIONS_FILTER
parameter is set to "true".
This parameter checks if the extensions-filter has been properly configured.
Why using JSF-RI 1.2_04 causes the problem is not yet examined.
To avoid generation of errors from MyFaces in case of invalid filter configuration you could set up the following parameters in web.xml:
...
<context-param>
<param-name>org.apache.myfaces.CHECK_EXTENSIONS_FILTER</param-name>
<param-value>false</param-value>
</context-param>
...
In case of JSF 1.2_04, upgrading to JSF-RI 1.2_07 (last stable version) works.
If you try to use RichFaces 3.2.0 with MyFaces 1.2.2 on a WebLogic 10 MP1 server the following error appears:
java.lang.IllegalStateException: Servlet response already use stream, Writer not possible
...
The same project works on Tomcat 6.016, Tomcat 5.5.25 WebLogic 10MP1 with RichFaces 3.1.4.
Switching to JSF-RI 1.2_07 fix the problem (see forum post)
Use the <rich:fileUpload> component and Seam multi-part filter at the same time.
Lack of specification on the Servlet level does not allow to use stuff doing the same thing. One of them should be turned off.