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> >>>>> >>>> >>>> >>>> >>> >>> >>> >> > > >
