The bug seems to be that primefaces tries to use the HtmlResponseWriterImpl instead of the PartialResponseWriterImpl...
Bruno On 12 July 2010 15:28, Bruno Aranda <[email protected]> wrote: > Yes, it looks to me like the same thing. That is the thread in the > primefaces forum: > > http://primefaces.prime.com.tr/forum/viewtopic.php?f=3&t=3265&p=15035 > > On 12 July 2010 15:21, Marcus Büttner <[email protected]> wrote: >> Hi, >> >> I've a similar problem with primefaces and myfaces. The standard <f:ajax> to >> rerender a component works as espected but <p:ajax> do not update other >> primefaces components. I've posted it to the primefaces forum but with >> mojarra it seems to work. >> >> my example: >> >> <h:form id="myForm"> >> <h:selectOneMenu id="selectMenu" value="#{myBean.menuValue}"> >> <f:selectItem itemValue="true" itemLabel="Yes"/> >> <f:selectItem itemValue="false" itemLabel="No"/> >> <p:ajax event="change" update="output" process="selectMenu"/> >> </h:selectOneMenu> >> <p:inputMask id="output" mask="" value="#{myBean.menuValue}"/> >> <h:commandButton action="action"/> >> </h:form> >> >> Could this be the same cause? >> >> Marcus >> >> Bruno Aranda schrieb: >>> >>> I think you may be right, I have tried to test cases (attached to the >>> JIRA ticket). One using a primefaces button and the other using a jsf >>> standard button, and the latter works as expected. >>> >>> Bruno >>> >>> On 12 July 2010 15:03, Werner Punz <[email protected]> wrote: >>> >>>> >>>> Superb, as I said I am not entirely sure if myfaces is at fault here, my >>>> personal guess goes towards a custom partial response writer on the >>>> PrimeFaces side, but I am guessing here, because we have fallback code in >>>> our ppr responseWriter which exactly should cover what we have here: >>>> >>>> private String postProcess(StackEntry currentElement) throws >>>> IOException >>>> { >>>> >>>> currentElement.getWriter().flush(); >>>> StringBuffer buffer = currentElement.getDoubleBuffer().getBuffer(); >>>> >>>> String resultString = buffer.toString(); >>>> //section http://www.w3.org/TR/REC-xml/#sec-cdata-sect everything >>>> is >>>> parsed >>>> //until it hits a ]]> hence we need to do some mapping here >>>> >>>> //ok since our maximum string size is Integer.MAX_VALUE (most JVMs >>>> use char [] as >>>> //representations >>>> //we can work on strings directly, instead of having to go through >>>> streams >>>> //it is absolutely unlikely that we will ever have a buffered >>>> stream >>>> bigger than that >>>> //for our writer! >>>> if (resultString.contains("]]>")) { >>>> >>>> //we now first remove pending javascript CDATA blocks >>>> //the reason is if we leave them the ppr chokes on them >>>> //the syntax from the auto generated CDATA usually is >>>> //\s+<![CDATA[ >>>> resultString = >>>> resultString.replaceAll("//\\s*((\\<\\!\\[CDATA\\[)|(\\]\\]\\>))", ""); >>>> //now to fullfill the xml spec we have to replace all ]] with >>>> blocks of cdata >>>> resultString = resultString.replaceAll("\\]\\]\\>", >>>> "]]><![CDATA[]]]]><![CDATA[>"); >>>> } >>>> return resultString; >>>> } >>>> >>>> The idea is to double buffer a ppr cdata block and do some final >>>> postprocessing by excaping ]]> by valid cadata escapes. >>>> So this section should never be rendered that way >>>> >>>>>>>> >>>>>>>> //]]></script> >>>>>>>> >>>> >>>> would have been crrect >>>> ]]><![CDATA[]]]]><![CDATA[></script> >>>> >>>> instead it should have gotten a split into two cdata blocks. >>>> But we may have a bug here as well. >>>> >>>> Werner >>>> >>>> >>>> >>>> >>>> Am 12.07.10 15:52, schrieb Bruno Aranda: >>>> >>>>> >>>>> I will create a simple test case, >>>>> >>>>> Cheers, >>>>> >>>>> Bruno >>>>> >>>>> On 12 July 2010 14:47, Werner Punz<[email protected]> wrote: >>>>> >>>>>> >>>>>> Hi Bruno can you file a snippet of the original xhtml markup into >>>>>> >>>>>> https://issues.apache.org/jira/browse/MYFACES-2811 >>>>>> >>>>>> Werner >>>>>> >>>>>> >>>>>> >>>>>> Am 12.07.10 15:33, schrieb Werner Punz: >>>>>> >>>>>>> >>>>>>> Hi Bruno, please file a bugreport on it. We should fix this before >>>>>>> 2.0.1 >>>>>>> this is a bug in the ppr responsewriter on the server side. I was >>>>>>> fixing >>>>>>> exactly this issue a few months ago, maybe we have some regression bug >>>>>>> here. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Werner >>>>>>> >>>>>>> Am 12.07.10 14:48, schrieb Bruno Aranda: >>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have a partial response that contains invalid syntax because CDATA >>>>>>>> sections are nested. For example, in my app this code is generated in >>>>>>>> the partial response: >>>>>>>> >>>>>>>> <?xml version="1.0" >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> encoding="UTF-8"?><partialResponse><components><component><id>editorForm</id><output><![CDATA[<form >>>>>>>> >>>>>>>> id="editorForm" name="editorForm" method="post" >>>>>>>> action="/editor/curate/publication.jsf?conversationContext=2" >>>>>>>> enctype="application/x-www-form-urlencoded"><span >>>>>>>> id="growl"></span><script type="text/javascript">//<![CDATA[ >>>>>>>> jQuery.gritter.add({title:'Publication saved',text:'AC: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> EBI-2637354',image:'/editor/primefaces_resource/2.0.3-SNAPSHOT/primefaces/growl/assets/info.png?conversationContext=2',sticky:false}); >>>>>>>> >>>>>>>> >>>>>>>> //]]></script> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >> >> >
