[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer

[Werner Punz (Jira)]

    [ 
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756573#comment-17756573
 ] 

Werner Punz commented on MYFACES-4536:
--------------------------------------

Ok... the double buffering was there for only one reason, if you have a CDATA 
element with some embedded CDATA in (AKA hosting another CDATA element for 
instance in some embedded html like update etc...) it runs another encoding 
step to get this out aka <![CDATA becomes &lt;![CDATA

 

This is valid behavior in a sense that html code can embed javascript (there is 
an internal parsing step on the client side to cover this case)

And a valid usecase to define a script block is

<script

//<![CDATA[

 

what should not happen is to strip out the CDATA from the eval section, this is 
a bug! 

I will fix this one.

 

 

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