You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Bruno Aranda <br...@gmail.com> on 2010/07/12 14:48:25 UTC
Problem with nested CDATA sections in scripts in a PPR
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>
...
I use Primefaces, which is generating the script section inside the
partial response (in this case, the growl renderer). MyFaces wraps the
script content in a CDATA section. However, because the output section
itself has the CDATA this is provoking the problem. The agent thinks
that the first CDATA is closed when it reachs the end of the nested
CDATA, creating an invalid response.
Any ideas?
Bruno
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Werner Punz <we...@gmail.com>.
Hi Bruno you found out the same thing as I did locally here.
I read the third page
The issue is, that Primefaces rolls out its own partial request/
response mechanism instead of utilizing the jsf2 infrastructure and he
made the same mistake we did originally by relying on the ResponseWriter
to escape ]]> sections in a startCDATA and endCDATA. Now the problem is
that the spec does not enforce this behavior and both impls for speed
reasons left it out per default.
We fixed the issue on the PartialResponseWriter level (and induced a
small speed hit that way), same did Mojarra I guess.
That does not help if the library rolls its own responseWriter and falls
again into the same spec hole - trap.
I have filed all this into the issue, and lets see what comes out of it.
My personal preferrence is to have this fixed first on primefaces level
and if the need arises have this fixed on spec level as well or by
synchronizing both impls in their default behavior in this area.
But in the end Leonardo has the final word on this, he is the core
maintaner.
Werner
Am 12.07.10 16:28, schrieb Bruno Aranda:
> 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<mb...@buett.at> 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<we...@gmail.com> 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<we...@gmail.com> 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>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Werner Punz <we...@gmail.com>.
He cannot really uses the partialresonsewriterimpl, because he rolls his
own custom ppr protocol, but he also has to add the fixups we did for
the ppr responsewriter (were control over cdata blocks were removed from
the users hands to some degree)
The fixup is relatively easy but induces a speed hit because you have to
double escape embedded ]]> blocks via regexps since the xml spec clearly
says that a CDATA block has to end with ]]> and non ]]> is allowed in
between.
Werner
Am 12.07.10 16:41, schrieb Bruno Aranda:
> 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<br...@gmail.com> 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<mb...@buett.at> 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<we...@gmail.com> 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<we...@gmail.com> 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>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Bruno Aranda <br...@gmail.com>.
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 <br...@gmail.com> 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 <mb...@buett.at> 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 <we...@gmail.com> 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<we...@gmail.com> 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>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Bruno Aranda <br...@gmail.com>.
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 <mb...@buett.at> 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 <we...@gmail.com> 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<we...@gmail.com> 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>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Werner Punz <we...@gmail.com>.
Well the problem also is on Mojarra, it simply slept through.
Primefaces seems to run its own ajax cycle anyway and for now does not
leverage in this area what jsf2 has to offer otherwise the bug would not
have occurred.
Werner
Am 12.07.10 19:17, schrieb Matthias Wessendorf:
> It's a little bit lame that the primefaces guys never run their tests
> with MyFaces.
>
> -Matthias
>
> On Mon, Jul 12, 2010 at 7:21 AM, Marcus Büttner<mb...@buett.at> 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<we...@gmail.com> 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<we...@gmail.com> 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>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
>
>
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Matthias Wessendorf <ma...@apache.org>.
It's a little bit lame that the primefaces guys never run their tests
with MyFaces.
-Matthias
On Mon, Jul 12, 2010 at 7:21 AM, Marcus Büttner <mb...@buett.at> 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 <we...@gmail.com> 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<we...@gmail.com> 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>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Marcus Büttner <mb...@buett.at>.
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 <we...@gmail.com> 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<we...@gmail.com> 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>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Bruno Aranda <br...@gmail.com>.
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 <we...@gmail.com> 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<we...@gmail.com> 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>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Werner Punz <we...@gmail.com>.
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<we...@gmail.com> 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>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Bruno Aranda <br...@gmail.com>.
I will create a simple test case,
Cheers,
Bruno
On 12 July 2010 14:47, Werner Punz <we...@gmail.com> 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>
>>>
>>
>>
>>
>
>
>
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Werner Punz <we...@gmail.com>.
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>
>>
>
>
>
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Werner Punz <we...@gmail.com>.
Hi Bruno, can you drop the snippet of the original jsf code also, I need
to setup a testcase and also need to know which component is at fault
here. I rechecked our code, theoretically this should be covered in our
PartialResponseWriterImpl, I suspect primefaces running its own
responseWriter here, but for that I need a testcase scenario which
resembles your usecase.
Werner
Am 12.07.10 15:44, schrieb Bruno Aranda:
> No no, it is already filed! :)
>
> https://issues.apache.org/jira/browse/MYFACES-2812
>
> Cheers,
>
> Bruno
>
> On 12 July 2010 14:42, Werner Punz<we...@gmail.com> wrote:
>> Never mind, I will file it myself.
>>
>> 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>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Bruno Aranda <br...@gmail.com>.
No no, it is already filed! :)
https://issues.apache.org/jira/browse/MYFACES-2812
Cheers,
Bruno
On 12 July 2010 14:42, Werner Punz <we...@gmail.com> wrote:
> Never mind, I will file it myself.
>
> 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>
>>>
>>
>>
>>
>
>
>
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Werner Punz <we...@gmail.com>.
Never mind, I will file it myself.
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>
>>
>
>
>
Re: Problem with nested CDATA sections in scripts in a PPR
Posted by Werner Punz <we...@gmail.com>.
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>
>