[ 
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 3:39 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!

 


was (Author: werpu):
Hi I have started to look into it now, its been a while since I looked into it, 
but the problem maybe related to the xml filter

public PartialResponseWriterImpl(ResponseWriter writer)

{ super(writer.cloneWithWriter(new IllegalXmlCharacterFilterWriter(writer))); }

 

Which in itself fixes another issue which myfaces had with illegal characters. 
I will post info when I know more of the real cause.

As for the double buffering response writer, I think it has to do with the 
problem that if you embed cdata into cdata you have the "escape" it by 
splitting it into several cdata sections.

Hence this probably was done this way. But all of this atm is just guessing! I 
will debug this out tonight! To get a better idea what is happening!

 

 

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

Reply via email to