[jira] [Comment Edited] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771338#comment-17771338 ] Werner Punz edited comment on MYFACES-4630 at 10/3/23 5:39 AM: --- No they are more a goody than anything else, you do not necessarily need them, they might save a little bit of bandwith though (not that important but it was a low hanging fruit), you can turn the build off in the node file! Shall we turn them off, saves a little bit of space? The map files are mandatory however! Otherwise debugging the scripts wont work (aka wont show the typscript sources during debugging instead of the js sources)! I would not recommend to turn them off for the development version, having a working debugging possibility which shows the typescripts is a must! was (Author: werpu): No they are more a goody than anything else, you do not necessarily need them, they might save a little bit of bandwith though (not that important but it was a low hanging fruit), you can turn the build of them off in the node file! Shall we turn them off, saves a little bit of space? The map files are mandatory however! Otherwise debugging the scripts wont work (aka wont show the typscript sources during debugging instead of the js sources)! I would not recommend to turn them off for the development version, having a working debugging possibility which shows the typescripts is a must! > Compressed Files Necessary in 4.0 API? > -- > > Key: MYFACES-4630 > URL: https://issues.apache.org/jira/browse/MYFACES-4630 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > The API contains the following files: > META-INF/resources/jakarta.faces/faces.js.br > META-INF/resources/jakarta.faces/faces-development.js.br > META-INF/resources/jakarta.faces/faces.js > META-INF/resources/jakarta.faces/faces-development.js.map > META-INF/resources/jakarta.faces/faces-development.js > META-INF/resources/jakarta.faces/faces.js.gz > META-INF/resources/jakarta.faces/faces.js.map > META-INF/resources/jakarta.faces/faces-development.js.gz > Is it necessary to have the .br, .map, and .gz files? If not, could we > remove them to reduce the API size by a bit? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771338#comment-17771338 ] Werner Punz edited comment on MYFACES-4630 at 10/3/23 5:38 AM: --- No they are more a goody than anything else, you do not necessarily need them, they might save a little bit of bandwith though (not that important but it was a low hanging fruit), you can turn the build of them off in the node file! Shall we turn them off, saves a little bit of space? The map files are mandatory however! Otherwise debugging the scripts wont work (aka wont show the typscript sources during debugging instead of the js sources)! I would not recommend to turn them off for the development version, having a working debugging possibility which shows the typescripts is a must! was (Author: werpu): No they are more a goody than anything else, you do not necessarily need them, they were a low hanging fruit, you can turn the build of them off in the node file! Shall we turn them off, saves a little bit of space? The map files are mandatory however! Otherwise debugging the scripts wont work! > Compressed Files Necessary in 4.0 API? > -- > > Key: MYFACES-4630 > URL: https://issues.apache.org/jira/browse/MYFACES-4630 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > The API contains the following files: > META-INF/resources/jakarta.faces/faces.js.br > META-INF/resources/jakarta.faces/faces-development.js.br > META-INF/resources/jakarta.faces/faces.js > META-INF/resources/jakarta.faces/faces-development.js.map > META-INF/resources/jakarta.faces/faces-development.js > META-INF/resources/jakarta.faces/faces.js.gz > META-INF/resources/jakarta.faces/faces.js.map > META-INF/resources/jakarta.faces/faces-development.js.gz > Is it necessary to have the .br, .map, and .gz files? If not, could we > remove them to reduce the API size by a bit? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771339#comment-17771339
]
Werner Punz edited comment on MYFACES-4536 at 10/3/23 5:36 AM:
---
[~melloware] could you make it work, if not then I have to look into the other
responsewriters, to find which one is responsible to cause such a behavior in
the chain!
was (Author: werpu):
[~melloware] could you make it work, if not then I have to look into the other
responsewriters, to find which one is at culprit here!
> 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, image-2023-10-02-20-33-05-162.png,
> 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)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771339#comment-17771339
]
Werner Punz commented on MYFACES-4536:
--
[~melloware] could you make it work, if not then I have to look into the other
responsewriters, to find which one is at culprit here?
> 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, image-2023-10-02-20-33-05-162.png,
> 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)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771339#comment-17771339
]
Werner Punz edited comment on MYFACES-4536 at 10/3/23 5:35 AM:
---
[~melloware] could you make it work, if not then I have to look into the other
responsewriters, to find which one is at culprit here!
was (Author: werpu):
[~melloware] could you make it work, if not then I have to look into the other
responsewriters, to find which one is at culprit here?
> 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, image-2023-10-02-20-33-05-162.png,
> 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)
[jira] [Comment Edited] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771338#comment-17771338 ] Werner Punz edited comment on MYFACES-4630 at 10/3/23 5:34 AM: --- No they are more a goody than anything else, you do not necessarily need them, they were a low hanging fruit, you can turn the build of them off in the node file! Shall we turn them off, saves a little bit of space? The map files are mandatory however! Otherwise debugging the scripts wont work! was (Author: werpu): No they are more a goody than anything else, you do not necessarily need them, they were a low hanging fruit, you can turn the build of them off in the node file! Shall we turn them off, saves a little bit of space? > Compressed Files Necessary in 4.0 API? > -- > > Key: MYFACES-4630 > URL: https://issues.apache.org/jira/browse/MYFACES-4630 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > The API contains the following files: > META-INF/resources/jakarta.faces/faces.js.br > META-INF/resources/jakarta.faces/faces-development.js.br > META-INF/resources/jakarta.faces/faces.js > META-INF/resources/jakarta.faces/faces-development.js.map > META-INF/resources/jakarta.faces/faces-development.js > META-INF/resources/jakarta.faces/faces.js.gz > META-INF/resources/jakarta.faces/faces.js.map > META-INF/resources/jakarta.faces/faces-development.js.gz > Is it necessary to have the .br, .map, and .gz files? If not, could we > remove them to reduce the API size by a bit? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771338#comment-17771338 ] Werner Punz edited comment on MYFACES-4630 at 10/3/23 5:33 AM: --- No they are more a goody than anything else, you do not necessarily need them, they were a low hanging fruit, you can turn the build of them off in the node file! Shall we turn them off, saves a little bit of space? was (Author: werpu): No they are more a goody than anything else, you do not necessarily need them, they were a low hanging fruit, you can turn the build of them off in the node file! > Compressed Files Necessary in 4.0 API? > -- > > Key: MYFACES-4630 > URL: https://issues.apache.org/jira/browse/MYFACES-4630 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > The API contains the following files: > META-INF/resources/jakarta.faces/faces.js.br > META-INF/resources/jakarta.faces/faces-development.js.br > META-INF/resources/jakarta.faces/faces.js > META-INF/resources/jakarta.faces/faces-development.js.map > META-INF/resources/jakarta.faces/faces-development.js > META-INF/resources/jakarta.faces/faces.js.gz > META-INF/resources/jakarta.faces/faces.js.map > META-INF/resources/jakarta.faces/faces-development.js.gz > Is it necessary to have the .br, .map, and .gz files? If not, could we > remove them to reduce the API size by a bit? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771338#comment-17771338 ] Werner Punz commented on MYFACES-4630: -- No they are more a goody than anything else, you do not necessarily need them, they were a low hanging fruit, you can turn the build of them off in the node file! > Compressed Files Necessary in 4.0 API? > -- > > Key: MYFACES-4630 > URL: https://issues.apache.org/jira/browse/MYFACES-4630 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Volodymyr Siedlecki >Assignee: Werner Punz >Priority: Major > > The API contains the following files: > META-INF/resources/jakarta.faces/faces.js.br > META-INF/resources/jakarta.faces/faces-development.js.br > META-INF/resources/jakarta.faces/faces.js > META-INF/resources/jakarta.faces/faces-development.js.map > META-INF/resources/jakarta.faces/faces-development.js > META-INF/resources/jakarta.faces/faces.js.gz > META-INF/resources/jakarta.faces/faces.js.map > META-INF/resources/jakarta.faces/faces-development.js.gz > Is it necessary to have the .br, .map, and .gz files? If not, could we > remove them to reduce the API size by a bit? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771326#comment-17771326 ] Volodymyr Siedlecki commented on MYFACES-4630: -- [~werpu] I'll assign it to you since you know this code base better. I don't see any references to these in the java files, so I'm think they could be removed? However, there might be some background knowledge I'm not aware of. Thanks! > Compressed Files Necessary in 4.0 API? > -- > > Key: MYFACES-4630 > URL: https://issues.apache.org/jira/browse/MYFACES-4630 > Project: MyFaces Core > Issue Type: Improvement >Affects Versions: 4.0.1 >Reporter: Volodymyr Siedlecki >Priority: Major > > The API contains the following files: > META-INF/resources/jakarta.faces/faces.js.br > META-INF/resources/jakarta.faces/faces-development.js.br > META-INF/resources/jakarta.faces/faces.js > META-INF/resources/jakarta.faces/faces-development.js.map > META-INF/resources/jakarta.faces/faces-development.js > META-INF/resources/jakarta.faces/faces.js.gz > META-INF/resources/jakarta.faces/faces.js.map > META-INF/resources/jakarta.faces/faces-development.js.gz > Is it necessary to have the .br, .map, and .gz files? If not, could we > remove them to reduce the API size by a bit? > Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
Volodymyr Siedlecki created MYFACES-4630: Summary: Compressed Files Necessary in 4.0 API? Key: MYFACES-4630 URL: https://issues.apache.org/jira/browse/MYFACES-4630 Project: MyFaces Core Issue Type: Improvement Affects Versions: 4.0.1 Reporter: Volodymyr Siedlecki The API contains the following files: META-INF/resources/jakarta.faces/faces.js.br META-INF/resources/jakarta.faces/faces-development.js.br META-INF/resources/jakarta.faces/faces.js META-INF/resources/jakarta.faces/faces-development.js.map META-INF/resources/jakarta.faces/faces-development.js META-INF/resources/jakarta.faces/faces.js.gz META-INF/resources/jakarta.faces/faces.js.map META-INF/resources/jakarta.faces/faces-development.js.gz Is it necessary to have the .br, .map, and .gz files? If not, could we remove them to reduce the API size by a bit? Thanks! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4606) Missing source button id:value pair from request parameters in ajax requests
[
https://issues.apache.org/jira/browse/MYFACES-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771244#comment-17771244
]
Werner Punz edited comment on MYFACES-4606 at 10/2/23 6:45 PM:
---
Will look at this. We probably simply cannot attach a key value pair for
elements exposing this behavior, to my knowledge only checkboxes and radio
buttons should be affected by this, because they can hold values but expose the
values only by their respective state.
The internal code check does not test for type but only if a value is present,
however in case of a checkbox or radio button the flag checked is the
overriding flag here.
was (Author: werpu):
Will look at this.
> Missing source button id:value pair from request parameters in ajax requests
>
>
> Key: MYFACES-4606
> URL: https://issues.apache.org/jira/browse/MYFACES-4606
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.15, 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3, 2.2.16, 4.0.2
>
>
> When the non-ajax submit button is pressed, its id and value is sent as a
> request parameter. If the ajax equivalent button is pressed, the id-value
> pair is missing. However, the id is included under the "javax.faces.source"
> attribute, per the spec.
> This becomes a problem if you do some param checks (via binding attr.) to see
> if a particular button is pressed. See more info about this here:
> [https://stackoverflow.com/a/14730658/11402059]
> Here's a sample of the behaviors for ajax and non ajax submissions. The
> required parts are in red (which should appear in both requests):
> {code:java}
>
> Ajax Checkboxes:
>
>
>
>
> Message for ajaxCheckbox ->
>
> Non-Ajax Checkboxes:
>
>
>
>
> Message for nonajaxCheckbox -> :
>
>
>
>
>
> binding="#{nonajaxbtn}"/>
>
> value="#{entry.key}" /> :
>
>
> {code}
>
> It used to work in 2.0, but now fails after refactoring. Haven't tested on
> 4.0, but I think it's also affected.
> 2.3.x:
> [https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L38-L63]
>
>
> 2.0.5:
> [https://github.com/apache/myfaces/blob/myfaces-core-project-2.0.5/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L57]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4606) Missing source button id:value pair from request parameters in ajax requests
[
https://issues.apache.org/jira/browse/MYFACES-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771244#comment-17771244
]
Werner Punz commented on MYFACES-4606:
--
Will look at this.
> Missing source button id:value pair from request parameters in ajax requests
>
>
> Key: MYFACES-4606
> URL: https://issues.apache.org/jira/browse/MYFACES-4606
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.15, 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3, 2.2.16, 4.0.2
>
>
> When the non-ajax submit button is pressed, its id and value is sent as a
> request parameter. If the ajax equivalent button is pressed, the id-value
> pair is missing. However, the id is included under the "javax.faces.source"
> attribute, per the spec.
> This becomes a problem if you do some param checks (via binding attr.) to see
> if a particular button is pressed. See more info about this here:
> [https://stackoverflow.com/a/14730658/11402059]
> Here's a sample of the behaviors for ajax and non ajax submissions. The
> required parts are in red (which should appear in both requests):
> {code:java}
>
> Ajax Checkboxes:
>
>
>
>
> Message for ajaxCheckbox ->
>
> Non-Ajax Checkboxes:
>
>
>
>
> Message for nonajaxCheckbox -> :
>
>
>
>
>
> binding="#{nonajaxbtn}"/>
>
> value="#{entry.key}" /> :
>
>
> {code}
>
> It used to work in 2.0, but now fails after refactoring. Haven't tested on
> 4.0, but I think it's also affected.
> 2.3.x:
> [https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L38-L63]
>
>
> 2.0.5:
> [https://github.com/apache/myfaces/blob/myfaces-core-project-2.0.5/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L57]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771243#comment-17771243
]
Werner Punz edited comment on MYFACES-4536 at 10/2/23 6:33 PM:
---
The behavior itself works:
[https://gist.github.com/werpu/3d3fdeaa8e75336f7aa5b63bd480b04c]
This test passes, so yes, the problem is not in the writer itself or the
partial response writer, so yes the csp response writer might be the culprit
here or another one in the chain:
!image-2023-10-02-20-33-05-162.png|width=435,height=72!
was (Author: werpu):
The behavior itself works:
[https://gist.github.com/werpu/3d3fdeaa8e75336f7aa5b63bd480b04c]
This test passes, so yes, the problem is not in the writer itself or the
partial response writer:
!image-2023-10-02-20-33-05-162.png|width=435,height=72!
> 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, image-2023-10-02-20-33-05-162.png,
> 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)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771243#comment-17771243
]
Werner Punz commented on MYFACES-4536:
--
The behavior itself works:
[https://gist.github.com/werpu/3d3fdeaa8e75336f7aa5b63bd480b04c]
This test passes, so yes, the problem is not in the writer itself or the
partial response writer:
!image-2023-10-02-20-33-05-162.png|width=435,height=72!
> 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, image-2023-10-02-20-33-05-162.png,
> 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)
[jira] [Commented] (MYFACES-4606) Missing source button id:value pair from request parameters in ajax requests
[
https://issues.apache.org/jira/browse/MYFACES-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771242#comment-17771242
]
Volodymyr Siedlecki commented on MYFACES-4606:
--
Hi, [~werpu]. We discovered a TCK failures after pulling this fix in 4.0.
[https://github.com/jakartaee/faces/blob/master/tck/faces22/ajax/src/test/java/ee/jakarta/tck/faces/test/servlet30/ajax_selenium/Issue2255IT.java#L48C44-L48C44]
My investigation showed that
`[divInComposite.xhtml`|https://github.com/jakartaee/faces/blob/4c5e8faab21db7edb9e32423bba056c06a0e3082/tck/faces22/ajax/src/main/webapp/divInComposite.xhtml#L26]
contains a boolean checkbox and we should not submit a value here.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/checkbox
Note: If a checkbox is unchecked when its form is submitted, neither the name
nor the value is submitted to the server. There is no HTML-only method of
representing a checkbox's unchecked state (e.g. value=unchecked). If you wanted
to submit a default value for the checkbox when it is unchecked, you could
include JavaScript to create a within the form with a
value indicating an unchecked state.
I'm wondering if checkbox is only exception? We may need a few checks here
before appending the issuing element.
Would you mind looking at this? Thank you.
> Missing source button id:value pair from request parameters in ajax requests
>
>
> Key: MYFACES-4606
> URL: https://issues.apache.org/jira/browse/MYFACES-4606
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 2.0.24, 2.2.15, 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
> Fix For: 2.3.11, 3.0.3, 2.2.16, 4.0.2
>
>
> When the non-ajax submit button is pressed, its id and value is sent as a
> request parameter. If the ajax equivalent button is pressed, the id-value
> pair is missing. However, the id is included under the "javax.faces.source"
> attribute, per the spec.
> This becomes a problem if you do some param checks (via binding attr.) to see
> if a particular button is pressed. See more info about this here:
> [https://stackoverflow.com/a/14730658/11402059]
> Here's a sample of the behaviors for ajax and non ajax submissions. The
> required parts are in red (which should appear in both requests):
> {code:java}
>
> Ajax Checkboxes:
>
>
>
>
> Message for ajaxCheckbox ->
>
> Non-Ajax Checkboxes:
>
>
>
>
> Message for nonajaxCheckbox -> :
>
>
>
>
>
> binding="#{nonajaxbtn}"/>
>
> value="#{entry.key}" /> :
>
>
> {code}
>
> It used to work in 2.0, but now fails after refactoring. Haven't tested on
> 4.0, but I think it's also affected.
> 2.3.x:
> [https://github.com/apache/myfaces/blob/2.3.x/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L38-L63]
>
>
> 2.0.5:
> [https://github.com/apache/myfaces/blob/myfaces-core-project-2.0.5/api/src/main/javascript/META-INF/resources/myfaces/_impl/xhrCore/_AjaxUtils.js#L57]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771239#comment-17771239
]
Melloware commented on MYFACES-4536:
OK I know in other places I have had to override the clone.
{code:java}
@Override
public ResponseWriter cloneWithWriter(Writer writer) {
return new CspResponseWriter(getWrapped().cloneWithWriter(writer),
this.cspState);
} {code}
> 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)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771238#comment-17771238
]
Werner Punz edited comment on MYFACES-4536 at 10/2/23 6:21 PM:
---
I think the main difference really is the wrapped here, let me try a test!
was (Author: werpu):
In my opinion the problem lies more on the way the response writer chain is
constructed, the way the writers are generated is that they are passed down and
cloned.
> 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)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771238#comment-17771238
]
Werner Punz commented on MYFACES-4536:
--
In my opinion the problem lies more on the way the response writer chain is
constructed, the way the writers are generated is that they are passed down and
cloned.
> 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)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771222#comment-17771222
]
Melloware commented on MYFACES-4536:
OK I just wanted to check so I implemented the change in PrimeFaces again and
our integration tests pass in Mojarra and fail in MyFaces:
https://github.com/primefaces/primefaces/actions/runs/6383060016
> 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)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771191#comment-17771191
]
Melloware commented on MYFACES-4536:
OK I think I might know what is going on let me try something.
> 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)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ 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:28 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 //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 // 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
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ 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 //{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 // {code} So the response writer behaves correctly if called directly in myfaces. > 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}}
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ 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 //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 // {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 >
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ 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:22 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 //{code} So the response writer behaves correctly if called directly in myfaces. 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 // 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)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ 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:47 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 // // 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)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ 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:40 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 // // 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)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ 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:40 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 // // 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)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[ 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 // 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)
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771165#comment-17771165
]
Werner Punz edited comment on MYFACES-4536 at 10/2/23 3:31 PM:
---
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!
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.
> 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)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771165#comment-17771165
]
Werner Punz commented on MYFACES-4536:
--
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.
> 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)
[jira] [Commented] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771077#comment-17771077
]
Melloware commented on MYFACES-4536:
[~tandraschko] I can try and take a look but I am definitely not fully
comfortable in this code base and understanding how some of these tests work.
> 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)
Re: [PR] chore: update checkstyle-rules [myfaces-tobago]
henningn merged PR #4355: URL: https://github.com/apache/myfaces-tobago/pull/4355 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] chore: update checkstyle-rules [myfaces-tobago]
henningn opened a new pull request, #4355: URL: https://github.com/apache/myfaces-tobago/pull/4355 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[PR] feature: Toasts [myfaces-tobago]
henningn opened a new pull request, #4354: URL: https://github.com/apache/myfaces-tobago/pull/4354 * tc:toasts implemented * add example Issue: TOBAGO-2231 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] build(deps): bump org.bsc.maven:maven-processor-plugin from 4.5-jdk8 to 5.0-jdk8 [myfaces-tobago]
henningn merged PR #4329: URL: https://github.com/apache/myfaces-tobago/pull/4329 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] build(deps): bump actions/checkout from 3 to 4 [myfaces-tobago]
henningn merged PR #4341: URL: https://github.com/apache/myfaces-tobago/pull/4341 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4337: build(deps-dev): bump rollup from 3.28.1 to 3.29.4 in /tobago-example/tobago-example-demo
henningn merged PR #4337: URL: https://github.com/apache/myfaces-tobago/pull/4337 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4339: build(deps-dev): bump rollup from 3.28.1 to 3.29.4 in /tobago-example/tobago-example-demo
henningn merged PR #4339: URL: https://github.com/apache/myfaces-tobago/pull/4339 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4351: build(deps-dev): bump @rollup/plugin-node-resolve from 15.1.0 to 15.2.1 in /tobago-theme
henningn merged PR #4351: URL: https://github.com/apache/myfaces-tobago/pull/4351 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn commented on pull request #4329: build(deps): bump org.bsc.maven:maven-processor-plugin from 4.5-jdk8 to 5.0-jdk8
henningn commented on PR #4329: URL: https://github.com/apache/myfaces-tobago/pull/4329#issuecomment-1742480042 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn commented on pull request #4341: build(deps): bump actions/checkout from 3 to 4
henningn commented on PR #4341: URL: https://github.com/apache/myfaces-tobago/pull/4341#issuecomment-1742479984 @dependabot rebase -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4353: build(deps): update commons-compress
henningn merged PR #4353: URL: https://github.com/apache/myfaces-tobago/pull/4353 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn opened a new pull request, #4353: build(deps): update commons-compress
henningn opened a new pull request, #4353: URL: https://github.com/apache/myfaces-tobago/pull/4353 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4342: build(deps): bump actions/checkout from 3 to 4
henningn merged PR #4342: URL: https://github.com/apache/myfaces-tobago/pull/4342 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4336: build(deps-dev): bump sass from 1.66.1 to 1.68.0 in /tobago-example/tobago-example-demo
henningn merged PR #4336: URL: https://github.com/apache/myfaces-tobago/pull/4336 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4340: build(deps-dev): bump @types/prismjs from 1.26.0 to 1.26.1 in /tobago-example/tobago-example-demo
henningn merged PR #4340: URL: https://github.com/apache/myfaces-tobago/pull/4340 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4338: build(deps-dev): bump sass from 1.66.1 to 1.68.0 in /tobago-example/tobago-example-demo
henningn merged PR #4338: URL: https://github.com/apache/myfaces-tobago/pull/4338 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4335: build(deps-dev): bump @types/prismjs from 1.26.0 to 1.26.1 in /tobago-example/tobago-example-demo
henningn merged PR #4335: URL: https://github.com/apache/myfaces-tobago/pull/4335 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4333: build(deps): bump actions/checkout from 3 to 4
henningn merged PR #4333: URL: https://github.com/apache/myfaces-tobago/pull/4333 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4334: build(deps): bump actions/checkout from 3 to 4
henningn merged PR #4334: URL: https://github.com/apache/myfaces-tobago/pull/4334 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4328: build(deps): bump spring-boot.version from 2.7.15 to 2.7.16
henningn merged PR #4328: URL: https://github.com/apache/myfaces-tobago/pull/4328 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4343: build(deps-dev): bump @rollup/plugin-typescript from 11.1.2 to 11.1.4 in /tobago-theme
henningn merged PR #4343: URL: https://github.com/apache/myfaces-tobago/pull/4343 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4344: build(deps-dev): bump eslint from 8.48.0 to 8.50.0 in /tobago-theme
henningn merged PR #4344: URL: https://github.com/apache/myfaces-tobago/pull/4344 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4345: build(deps-dev): bump jest and @types/jest in /tobago-theme
henningn merged PR #4345: URL: https://github.com/apache/myfaces-tobago/pull/4345 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4346: build(deps-dev): bump autoprefixer from 10.4.14 to 10.4.16 in /tobago-theme
henningn merged PR #4346: URL: https://github.com/apache/myfaces-tobago/pull/4346 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4348: build(deps): bump lit-html from 2.7.5 to 2.8.0 in /tobago-theme
henningn merged PR #4348: URL: https://github.com/apache/myfaces-tobago/pull/4348 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4349: build(deps-dev): bump @rollup/plugin-commonjs from 25.0.3 to 25.0.4 in /tobago-theme
henningn merged PR #4349: URL: https://github.com/apache/myfaces-tobago/pull/4349 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4352: build(deps-dev): bump jest and @types/jest in /tobago-theme
henningn merged PR #4352: URL: https://github.com/apache/myfaces-tobago/pull/4352 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
