[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165
]
Werner Punz edited comment on MYFACES-4536 at 10/2/23 4:24 PM:
---------------------------------------------------------------
Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I
wrote it, that embedded code can have cdata like
<![CDATA....
any script
<script>
//<![CDATA
...
now the problem is that in order to deliver a valid xml response, this
embededed code needs to have the cdata escaped. In order to do so, the code
breaks the single cdata section into several so that in restoration the code
should get a valid cdata block again once restoring it!
The implementation was, that wen this can be expected, I am simply overlaying
the response writer with some kind of double buffer which then is postprocessed
to generate a valid cdata response ... however as it seems there is a bug.
I will try to add a bunch of unit tests to nail this down once and forall!
I am not entirely convinced that the double buffering is the fault here, but
lets see what the unit tests produce!
A simple test produced following result
{code:java}
<?xml version="1.0"
encoding="UTF-8"?><partial-response><eval><![CDATA[if(window.PrimeFaces){PrimeFaces.csp.init('NjcwMDg5ZDgtYmEwZi00NDAzLWI3Y2MtZTk1OTY4Y2VjNzY2');};;PrimeFaces.csp.register('j_id_7k:j_id_7l:globalFilter','onchange',function(event){PF('customersTable').filter()});PrimeFaces.csp.register('j_id_7k:j_id_7l:j_id_7o','onclick',function(event){PrimeFaces.ab({s:"j_id_7k:j_id_7l:j_id_7o",f:"j_id_7k",u:"@form"});return
false;});;]]></eval></partial-response>
With following code:
_writer.startDocument();
_writer.startElement("eval", null);
_writer.startCDATA();
_writer.write("if(window.PrimeFaces){PrimeFaces.csp.init('NjcwMDg5ZDgtYmEwZi00NDAzLWI3Y2MtZTk1OTY4Y2VjNzY2');};;PrimeFaces.csp.register('j_id_7k:j_id_7l:globalFilter','onchange',function(event){PF('customersTable').filter()});PrimeFaces.csp.register('j_id_7k:j_id_7l:j_id_7o','onclick',function(event){PrimeFaces.ab({s:\"j_id_7k:j_id_7l:j_id_7o\",f:\"j_id_7k\",u:\"@form\"});return
false;});;");
_writer.endCDATA();
_writer.endElement("eval");
_writer.endDocument();{code}
So the response writer behaves correctly if called directly in myfaces. (just
for the protocol), I will try to replicate the primefaces case next! Still not
sure what the problem is, I cannot see it in the code itself either at writer
level.
was (Author: werpu):
Hi. I am looking into it, the code idea behind it, and I stated it in 13 when I
wrote it, that embedded code can have cdata like
<![CDATA....
any script
<script>
//<![CDATA
...
now the problem is that in order to deliver a valid xml response, this
embededed code needs to have the cdata escaped. In order to do so, the code
breaks the single cdata section into several so that in restoration the code
should get a valid cdata block again once restoring it!
The implementation was, that wen this can be expected, I am simply overlaying
the response writer with some kind of double buffer which then is postprocessed
to generate a valid cdata response ... however as it seems there is a bug.
I will try to add a bunch of unit tests to nail this down once and forall!
I am not entirely convinced that the double buffering is the fault here, but
lets see what the unit tests produce!
A simple test produced following result
{code:java}
<?xml version="1.0"
encoding="UTF-8"?><partial-response><eval><![CDATA[if(window.PrimeFaces){PrimeFaces.csp.init('NjcwMDg5ZDgtYmEwZi00NDAzLWI3Y2MtZTk1OTY4Y2VjNzY2');};;PrimeFaces.csp.register('j_id_7k:j_id_7l:globalFilter','onchange',function(event){PF('customersTable').filter()});PrimeFaces.csp.register('j_id_7k:j_id_7l:j_id_7o','onclick',function(event){PrimeFaces.ab({s:"j_id_7k:j_id_7l:j_id_7o",f:"j_id_7k",u:"@form"});return
false;});;]]></eval></partial-response> {code}
So the response writer behaves correctly if called directly in myfaces. (just
for the protocol), I will try to replicate the primefaces case next! Still not
sure what the problem is, I cannot see it in the code itself either at writer
level.
> PartialResponseWriter: Do no wrap the writer
> --------------------------------------------
>
> Key: MYFACES-4536
> URL: https://issues.apache.org/jira/browse/MYFACES-4536
> Project: MyFaces Core
> Issue Type: Improvement
> Components: General
> Affects Versions: 2.2.14, 2.3.10, 2.3-next-M7, 4.0.0-RC2
> Reporter: Melloware
> Assignee: Werner Punz
> Priority: Major
> Attachments: csp-results.zip, mojarra-csp-new.txt
>
>
> Per BalusC:
> Since JSF 2.3 the default constructor of {{FacesWrapper}} subclasses has been
> deprecated in order to force implementors to instead use the constructor
> taking the wrapped instance (and to raise their awareness), so that logically
> the inherited {{getWrapped()}} method will be used throughout the
> implementation instead of the local {{wrapped}} variable. This will ensure
> that the correct implementation is returned and correct behavior is performed
> might the {{FacesWrapper}} implementation itself being wrapped by yet another
> {{FacesWrapper}} implementation further down the chain. Because, when the
> {{FacesWrapper}} implementation incorrectly/accidentally uses the local
> {{wrapped}} variable instead of the {{getWrapped()}} method, then that other
> {{FacesWrapper}} implementation will basically be completely ignored, hereby
> breaking the decorator pattern.
>
> PrimeFaces ticket: https://github.com/primefaces/primefaces/issues/9518
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
