Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: 3.3.1, 4.0.0.Final
-
Fix Version/s: 4.2.1.CR1
-
Component/s: component-output, regression
-
Labels:None
-
Environment:Windows / JBoss 4.2.2.GA / Seam 2.1.1.GA / RichFaces 3.3.1.GA
Description
Looks like a regression of RF-615... I've upgraded my Seam project to sue RF 3.3.1, in order to fix a number of other bugs, but now messages intended for a single UI component (via the for= ) are appearing in the global messages list at the top of my page.
My page template has:
<rich:messages globalOnly="true" id="page-messages">
...
</rich:messages>
and the controls have:
<rich:message for="my-control-id" id="my-control-id-message">
...
</rich:message>
I can switch the rich:messages to h:messages, and it behaves as it should. Also reverting back to the RichFaces 3.2.2.SR1 jars makes the problem go away, but I get the other older bugs back 
Gliffy Diagrams
Issue Links
- is related to
-
RF-615
messages: globalOnly does not work properly
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
Thanks David,
Some extra info on the workaround.
The workaround as described above doesn't work in our case since facesMessages is not available (we don't have a seam-application like the reporter of this issue described).
However, we got the workaround to work by doing something similar.
.hidden {
|
display: none !important;
|
}
|
styleClass="#{workaroundForGlobalMessagesBug.showMessages() ? '' : 'hidden'}"
|
|
|
public boolean showMessages() {
|
Iterator<String> clientIds = FacesContext.getCurrentInstance().getClientIdsWithMessages();
|
while (clientIds.hasNext()) {
|
String clientId = clientIds.next();
|
if (clientId == null) {
|
return true;
|
}
|
}
|
return false;
|
}
|
The thing I don't completely get is that it doesn't work using the rendered property on rich:messages, we have to hide it with css.
Not sure why, but it seems to mess up the whole render-response part.
Mano Swerts
added a comment - Thanks David,
Some extra info on the workaround.
The workaround as described above doesn't work in our case since facesMessages is not available (we don't have a seam-application like the reporter of this issue described).
However, we got the workaround to work by doing something similar.
.hidden {
display: none !important;
}
styleClass="#{workaroundForGlobalMessagesBug.showMessages() ? '' : 'hidden'}"
public boolean showMessages() {
Iterator<String> clientIds = FacesContext.getCurrentInstance().getClientIdsWithMessages();
while (clientIds.hasNext()) {
String clientId = clientIds.next();
if (clientId == null) {
return true;
}
}
return false;
}
The thing I don't completely get is that it doesn't work using the rendered property on rich:messages, we have to hide it with css.
Not sure why, but it seems to mess up the whole render-response part. Hi Mano ! I'm glad to help you 
Try to reRender a outer element, or to put a a4j:outputPanel ajaxRendered="true":
<a:outputPanel ajaxRendered="true" id="messagesOuter">
<rich:messages id="richMessages" rendered="#{workaroundForGlobalMessagesBug.showMessages()"/>
</a:outputPanel>
If you reRender 'richMessages' the rendered is not reavaliated, only the children's 'rendered' is reavaliated.
david vieira
added a comment - Hi Mano ! I'm glad to help you
Try to reRender a outer element, or to put a a4j:outputPanel ajaxRendered="true":
<a:outputPanel ajaxRendered="true" id="messagesOuter">
<rich:messages id="richMessages" rendered="#{workaroundForGlobalMessagesBug.showMessages()"/>
</a:outputPanel>
If you reRender 'richMessages' the rendered is not reavaliated, only the children's 'rendered' is reavaliated. Hi Mano, David,
it would be very appreciated if you could provide testing sample minimized to show your case, since we are not able to reproduce it.
Lukáš Fryč
added a comment - Hi Mano, David,
it would be very appreciated if you could provide testing sample minimized to show your case, since we are not able to reproduce it. Hi All, I had small temporary workaround for this issue. Maybe it can help:
http://stackoverflow.com/a/9184935/706695
burak sarac
added a comment - Hi All, I had small temporary workaround for this issue. Maybe it can help:
http://stackoverflow.com/a/9184935/706695 I have run into the same issue with following sample:
https://github.com/lfryc/quickstart/tree/quickstart-28/richfaces-validation
The issue occurs when using <rich:validator />,
it means it can be reproduced only when using Client-Side Validation.
Lukáš Fryč
added a comment - - edited I have run into the same issue with following sample:
https://github.com/lfryc/quickstart/tree/quickstart-28/richfaces-validation
The issue occurs when using <rich:validator /> ,
it means it can be reproduced only when using Client-Side Validation. 
Not reproduced.
{controller.generateErrors()}My code:
test.xhtml:
<h:form>
<rich:messages globalOnly="true">
</rich:messages>
<h:inputText id="my-control-id" required="true" value=""></h:inputText>
<rich:message for="my-control-id" id="my-control-id-message">
</rich:message>
<a4j:commandButton actionlistener="#
" value="Submit"/>
</h:form>
Controller.generateErrors(){
UIComponent root = FacesContext.getCurrentInstance().getViewRoot();
UIComponent component = root.findComponent("mainform:my-control-id");
FacesContext.getCurrentInstance().addMessage(component
.getClientId(FacesContext.getCurrentInstance()),new FacesMessage(FacesMessage.SEVERITY_ERROR, "input error", "input error"));
}