Create new RichFaces Documentation Jira issue
This will launch the RichFaces Jira page - to complete your feedback please login if needed, and submit the Jira.
JBoss.orgCommunity Documentation
This chapter includes only those issues that concern migration from from 3.1.x versions to 3.2.0. Issues, related to the new components and other problems are not covered here. However, Jira contains all issues and if you can not find your case there, please, feel free to report it.
Migrating to RichFaces 3.2.0 you can encounter with malfunction of the components caused by a number of reasons. However, most of the problems can be positively solved. This section covers the most significant issues you can potentially encounter, providing ways to handle the cases.
An application with i18n does not work correctly due to the validation error that occurs when non-ASCII characters are 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>
...
You need to update to RichFaces 3.2.0 SP1
Menu components do not work 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, displaying a XHTML invalid output message
The described above problems occur if JSF-RI 1.2_08 and menu components are used on a page
It is a critical bug in JSF-RI 1.2_08 which has been already fixed in the further releases.
Upgrade to JSF-RI 1.2_09 or above
Binding does not work for all components in JSP: it is impossible to use the"binding" attribute for RichFaces components, since wrong class-name is used in TLD generated from XML configuration files.
The described above problem occurs if binding attribute is used with RichFaces components.
There was a wrong <classname>java.lang.String</classname> specified instead of <classname>javax.faces.component.UIComponent</classname> in configuration files.
The solution is to use Facelets upgrade to RichFaces 3.2.0 SP1
Ajax requests stop to work without any errors messages displayed, when intensive Ajax traffic is expected. No errors or other messages to detect cause of the defect are shown.
The described above problem occurs if an id for Ajax command component is not defined.
...
<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>
...
The problem occurred due to specific usage of the dynamic id generation implementing JSF 1.2. 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 of the component with old id is not processed.
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.
The described above problem usually occurs after server restart when user refreshes the page
The problem is caused when resources for standard skinning classes are not available to be 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.
This section covers issues you can encounter upgrading to RichFaces 3.2.0 from previous versions.
The <rich:calendar> date selected event is fired before input update.
If time and apply elements are added to the calendar, "ondateselected" gets fired when a date is selected but before it's 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.
The described above problem occurs when <a4j:support> is put inside <rich:calendar>. If the "event" property is set to "ondateselected" previous value of the <rich:calendar> is stored after selection.
Two <rich:datascroller> components bound to the same table aren't synchronized. Having two <rich:datascroller>components on a page, session-scoped beans saves the data for only one <rich:datascroller> component. It is a common pattern to have 2 <rich:datascroller> components: the first in the header, the second in the footer. In this case the first one will not work.
The described above problem occurs if two <rich:datascroller> components are added to any table.
The "for"attribute of <rich:datascroller> component 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.
The described above problem occurs if the following code is used:
...
<rich:datascroller for="#{bean.property}"/>
...
Please, see Jira
The RichFaces components that have "ajaxSingle" set to "true" does not work in "header" or "footer" facets of <h:dataTable>, e.g. <rich:datascroller> - scrolling doesn't work.
The described above problem occurs if the following code is used. As a result the <rich:datascroller> component stops working.
...
<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.
As it has been mentioned above we've migrated to JSF 1.2 standard in RichFaces 3.2.0. The order of calling action listeners has been changed in JSF 1.2: first the listener of the component itself is called then the other listeners are called.
This is why the <a4j:actionparam> component setter is called after
"actionListener" of the component itself.
In the following example #{bean.action} is called before #{bean.value}:
Example:
...
<a4:support actionListener="#{bean.action}" event="onclick">
<a4j:actionparam assignTo="#{bean.value}" value="John"/>
</a4j:support>
...
This issue occurs in JSP pages only.
...
<f:view>
<h:form>
<h:panelGrid width="120" border="5">
<a4j:support event="onclick" reRender="rep" actionListener="#{actionPlanBean.actionListener}">
<a4j:actionparam name="username" value="John" assignTo="#{actionPlanBean.name}" />
</a4j:support>
<h:outputLabel value="Panel 1 - John"/>
</h:panelGrid>
<rich:panel>
<h:outputText id="rep" value="I say: #{actionPlanBean.helloLabel}"/>
</rich:panel>
</h:form>
</f:view>
...
Please, see Jira.
Since we've migrated to the JSF 1.2 standard in RichFaces 3.2.0 the "immediate" attribute works exactly like it should according to the JSF 1.2 specification: the default ActionListener stops execution after the Apply Request Values phase, so there is no interaction with a model any more. We could not use the standard JSF API before as soon as we had to support not only JSF 1.2, but JSF 1.1 as well. We used our own hack that emulated the behavior of the attribute. This approach had a side effect that allowed interacting with a model but now this side effect is gone.
...
<h:form>
<h:inputText id="oneA" value="#{bean.name}" size="8">
<a4j:support event="onkeyup" reRender="three" immediate="true" focus="oneA" action="#{bean.actionOne}"/>
</h:inputText>
<h:selectBooleanCheckbox id="twoA" value="#{bean.option}">
<a4j:support event="onclick" reRender="three" immediate="true" focus="twoA" action="#{bean.actionOne}"/>
</h:selectBooleanCheckbox>
<h:commandButton id="go" value="Submit"/>
</h:form>
<h:outputText id="three" value="#{bean.name} #{bean.option}"/>
...
Behavior of the "immediate" attribute is changed according to to JSF 1.2 specification.
This section covers issues related to compatibility with third party frameworks.
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", the parameter checks if the extensions-filter has been properly configured.
The reason why usage of JSF-RI 1.2_04 causes the problem is not yet identified.
To avoid generation of errors from MyFaces in case of invalid filter configuration you can 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 fixes the problem (see forum post)
The problem occurs if you 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.