[richfaces-issues] [JBoss JIRA] (RF-12865) A4j:commandButton fail to render/update other components with MyFaces

[Brian Leathem (JIRA)]

    [ https://issues.jboss.org/browse/RF-12865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782195#comment-12782195 ] 

Brian Leathem commented on RF-12865:
------------------------------------

As reported in the user forum, this bug is only present when RichFaces is used in combination with OmniFaces.  See the following Omnifaces bug report for a clear explanation of the root cause from [~bauke]:

https://code.google.com/p/omnifaces/issues/detail?id=191

{quote}
This is a design bug in RichFaces. It's not utilizing standard JSF API facilities in its partial response writer. For some unobvious reason they stopped using PartialResponseWriter#endDocument() and added a custom finallyEndDocument() method which is not part of standard JSF API. This is only called by RichFaces own ExtendedPartialViewContextImpl. They also incorrectly assume that the RichFaces partial response writer would be the only response writer ever which is in use in the webapp. They do not take into account that partial response writers can be wrapped by another implementations and are supposed to delegate to the wrapped instance everytime. They do an instanceof check on the outermost wrapped instance only and if it's not an instance of their own response writer implementation (but e.g. the one of OmniFaces or even PrimeFaces), then they completely ignore it. They even don't even try to call the standard endDocument() method on it. In short, they are breaking the standard API.

See also source code for evidence: http://grepcode.com/file/repo1.maven.org/maven2/org.richfaces.core/richfaces-core-impl/4.3.1.CR1/org/richfaces/context/ExtendedPartialViewContextImpl.java#206

That is works with Mojarra is because it coincidentally loads the OmniFaces partial view context *before* the RichFaces one, so RichFaces always ends up getting its own response writer.

I'm not sure what to do here. I could expand our Hacks class with another one for RichFaces. It's already so full of ExtendedPartialViewContextImpl specific hacks.
{quote}

and

{quote}
I recommend to get rid of `finallyEndDocument()` and perform the job in `endDocument()`. I also recommend to let your partial view context impl extend from javax.faces.context.PartialViewContextWrapper to keep RichFaces friendly towards other JSF libraries which also offer a PVC wrapper. This should also eliminate verbose/strange ContextMode.DIRECT/WRAPPED boilerplate. As to "encoding issues" which the class' javadoc is talking about, I'm not sure what exactly you mean there, but I believe that it has the same grounds as this PrimeFaces problem: http://stackoverflow.com/a/9839362/157882 If this is true, just don't do that and clearly document to the enduser that it's his responsibility to explicitly configure the webapp and/or the server to use UTF-8 as request parameter/body encoding, which is at most a matter of a servlet fitler with an oneliner. This way you do not need to introduce wrapper modes in your partial view context (at least, I did not see a clear reason why you are doing that, other than the comment on top of the class).
{quote}

                
> A4j:commandButton fail to render/update other components with MyFaces
> ---------------------------------------------------------------------
>
>                 Key: RF-12865
>                 URL: https://issues.jboss.org/browse/RF-12865
>             Project: RichFaces
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: third-party
>    Affects Versions: 4.3.1
>         Environment: weblogic 10.3.4, Myfaces 2.1.10, Richfaces 4.3.1, OmniFaces1.3
>            Reporter: blam lam
>              Labels: waiting_on_user
>
> After submit from a a4j:commandButton, it fail to re-render / update other component on the page.
> This problem only appear in MyFaces. It does not happens in Mojarra.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira