Re: [VOTE] Release Tobago 6.4.0 and Tobago 5.12.0
+1 Werner Am So., 12. Mai 2024 um 12:42 Uhr schrieb Henning Nöth < henning.no...@irian.eu>: > Hello, > > we would like to release: > * Tobago 6.4.0 > * Tobago 5.12.0 > > The artifacts were deployed on nexus repository for binary and source > packages: > * Tobago 6.4.0 [1] > * Tobago 5.12.0 [1] > > The release notes are in Jira: > * Tobago 6.4.0 [2] > * Tobago 5.12.0 [3] > > The artifacts are available at the staging repository (Nexus) at: > * Tobago 6.4.0 [4] (sha-256 > 60e00050c84ee72e150cabc77cef030a15b90fc3995f8a7c024ee78a8b36a11c) > * Tobago 5.12.0 [5] (sha-256 > d13c0c853c139fd556a7a9c60c74f9674e57c218e5ed9e6b5153622fc0d63e45) > > Please vote now! (The vote is open for 72h.) > > [ ] +1 > [ ] +0 > [ ] -1 > > Regards, > Henning > > [1] > https://repository.apache.org/content/repositories/orgapachemyfaces-1248/ > [2] > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273=12354343 > [3] > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273=12354344 > [4] > > https://repository.apache.org/content/repositories/orgapachemyfaces-1248/org/apache/myfaces/tobago/tobago/6.4.0/tobago-6.4.0-source-release.zip > [5] > > https://repository.apache.org/content/repositories/orgapachemyfaces-1248/org/apache/myfaces/tobago/tobago/5.12.0/tobago-5.12.0-source-release.zip >
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[
https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844679#comment-17844679
]
Werner Punz edited comment on MYFACES-4378 at 5/8/24 2:45 PM:
--
Does not really matter, see my updated comment, the question is what the
resource id field itself is which gets updated, if it is a script tag then it
automatically gets evaled, but then the eval section is pointless, on the other
hand if you have the eval section you wont need the embedded script doing the
same.
This is a "garbage" response!
Btw forgot, the modern eval method for scripts is to append them to the head
and clear them out again, that way the browser safely can do the eval!
All 3 implementations of the scripts nowadays use this method for evaling js!
Might play into this, but this is just a sidenote!
{code:java}
// code placeholder
globalEval(code: string, nonce ?: string): DomQuery {
const head = document.getElementsByTagName("head")?.[0]
?? document.documentElement.getElementsByTagName("head")?.[0];
const script = document.createElement("script");
if (nonce) {
if ('undefined' != typeof script?.nonce) {
script.nonce = nonce;
} else {
script.setAttribute("nonce", nonce);
}
}
script.type = "text/javascript";
script.innerHTML = code;
let newScriptElement = head.appendChild(script);
head.removeChild(newScriptElement);
return this;
} {code}
What happens here is at the moment the script is appended it gets evaled by the
browser engine, and once evaled it is removed...
was (Author: werpu):
Does not really matter, see my updated comment, the question is what the
resource id field itself is which gets updated, if it is a script tag then it
automatically gets evaled, but then the eval section is pointless, on the other
hand if you have the eval section you wont need the embedded script doing the
same.
This is a "garbage" response!
Btw forgot, the modern eval method for scripts is to append them to the head
and clear them out again, that way the browser safely can do the eval!
All 3 implementations of the scripts nowadays use this method for evaling js!
Might play into this, but this is just a sidenote!
> onloadScript not rendering with non ajax command button if jstl type tag c:if
> is present on the page
>
>
> Key: MYFACES-4378
> URL: https://issues.apache.org/jira/browse/MYFACES-4378
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
>Priority: Minor
> Attachments: pf-11780.zip, test.7z
>
>
> See https://github.com/omnifaces/omnifaces/issues/366
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844679#comment-17844679 ] Werner Punz edited comment on MYFACES-4378 at 5/8/24 2:43 PM: -- Does not really matter, see my updated comment, the question is what the resource id field itself is which gets updated, if it is a script tag then it automatically gets evaled, but then the eval section is pointless, on the other hand if you have the eval section you wont need the embedded script doing the same. This is a "garbage" response! Btw forgot, the modern eval method for scripts is to append them to the head and clear them out again, that way the browser safely can do the eval! All 3 implementations of the scripts nowadays use this method for evaling js! Might play into this, but this is just a sidenote! was (Author: werpu): Does not really matter, see my updated comment, the question is what the resource id field itself is which gets updated, if it is a script tag then it automatically gets evaled, but then the eval section is pointless, on the other hand if you have the eval section you wont need the embedded script doing the same. This is a "garbage" response! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844679#comment-17844679 ] Werner Punz commented on MYFACES-4378: -- Does not really matter, see my updated comment, the question is what the resource id field itself is which gets updated, if it is a script tag then it automatically gets evaled, but then the eval section is pointless, on the other hand if you have the eval section you wont need the embedded script doing the same. This is a "garbage" response! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844671#comment-17844671 ] Werner Punz edited comment on MYFACES-4378 at 5/8/24 2:39 PM: -- I just checked our scripts, there is no dedicated handling of a javax.faces.Resource field... If there is one, it would only get executed/evaled automatically if it is of type script type="text/javascript" in this case the eval would not be needed, in the second case if there is an eval, then a script type="text/javascript" id="javax.faces.Resource" is pointless and you would get a double eval, but the culprit here is a renderer sending such a response! the namespace javax.faces.Resource normally is for resource requests not render areas, but using it is not a spec violation to my knowledge, any id on a script would have produced the same result! was (Author: werpu): yes the resource part is definitely wrong here... not sure why this is done both ways.. eval suffices to get the script executed, resource is for appending new resources (aka script links, css links etc...) not adding putting scripts as CDATA blocks... Eval is clearly stated being for script blocks which needs separate evaluation! I nevertheless will check our resource section what it does just in case to make sure that we do not get double includes in... Either way, it is either or not both... you will get a double execution this way! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844671#comment-17844671 ] Werner Punz edited comment on MYFACES-4378 at 5/8/24 2:32 PM: -- yes the resource part is definitely wrong here... not sure why this is done both ways.. eval suffices to get the script executed, resource is for appending new resources (aka script links, css links etc...) not adding putting scripts as CDATA blocks... Eval is clearly stated being for script blocks which needs separate evaluation! I nevertheless will check our resource section what it does just in case to make sure that we do not get double includes in... Either way, it is either or not both... you will get a double execution this way! was (Author: werpu): yes the resource part is definitely wrong here... not sure why this is done both ways.. eval suffices to get the script executed, resource is for appending new resources (aka script links, css links etc...) not adding putting scripts as CDATA blocks... Eval is clearly stated being for script blocks which needs separate evaluation! I nevertheless will check our resource section what it does just in case to make sure that we do not get double includes in... > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844671#comment-17844671 ] Werner Punz commented on MYFACES-4378: -- yes the resource part is definitely wrong here... not sure why this is done both ways.. eval suffices to get the script executed, resource is for appending new resources (aka script links, css links etc...) not adding putting scripts as CDATA blocks... Eval is clearly stated being for script blocks which needs separate evaluation! I nevertheless will check our resource section what it does just in case to make sure that we do not get double includes in... > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843571#comment-17843571 ] Werner Punz edited comment on MYFACES-4378 at 5/5/24 2:33 PM: -- Well, I dont think the new typescript based myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and provides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! was (Author: werpu): Well, I dont think the new myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and provides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843571#comment-17843571 ] Werner Punz edited comment on MYFACES-4378 at 5/5/24 2:32 PM: -- Well, I dont think the new myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and provides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! was (Author: werpu): Well, I dont think the new myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and prov ides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4378) onloadScript not rendering with non ajax command button if jstl type tag c:if is present on the page
[ https://issues.apache.org/jira/browse/MYFACES-4378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843571#comment-17843571 ] Werner Punz commented on MYFACES-4378: -- Well, I dont think the new myfaces code is affected by this issue, we do as far as I remember a proper head cleanup to avoid exactly this situation! But given that primefaces overrides the implementation and prov ides its own ajax implementation the culprit here is primefaces itself. Caveat, if I have understood the issue correctly! > onloadScript not rendering with non ajax command button if jstl type tag c:if > is present on the page > > > Key: MYFACES-4378 > URL: https://issues.apache.org/jira/browse/MYFACES-4378 > Project: MyFaces Core > Issue Type: Task >Affects Versions: 2.3.10, 2.3-next-M8, 4.0.2, 4.1.0-RC1 >Reporter: Thomas Andraschko >Assignee: Thomas Andraschko >Priority: Minor > Attachments: pf-11780.zip, test.7z > > > See https://github.com/omnifaces/omnifaces/issues/366 -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [VOTE] Release of MyFaces Core 4.10-RC2
+1 Melloware Inc schrieb am Sa., 27. Apr. 2024, 04:40: > +1 > > Melloware > @melloware on GitHub > > On Apr 26, 2024, at 4:54 PM, Volodymyr Siedlecki > wrote: > > > Hi, > > I was running the needed tasks to get the 4.1.0-RC2 release of Apache > MyFaces core out. > > Please note that this vote concerns all of the following parts: >1. Maven artifact group “org.apache.myfaces.core” v4.1.0-RC2 [1] > > The artifacts were deployed on nexus repo [1] for binary and source > packages. > > The release notes could be found at [4]. > > The japicmp tool shows no binary incompatibilities with 4.1.0-RC1. > Please take a look at the attached results.html. > > This release has not yet been run against the TCK. > > Please take a look at the “4.1.0-RC2" artifacts and vote! (see [3]) > > Please note: This vote is “majority approval” with a minimum of three +1 > votes (see [2]). > > > [ ] +1 for community members who have reviewed the bits > [ ] +0 > [ ] -1 for fatal flaws that should cause these bits not to be released, and > why. > > > Thanks, > > Volodymyr > > [1] > https://repository.apache.org/content/repositories/orgapachemyfaces-1247/org/apache/myfaces/core/ > [2] http://www.apache.org/foundation/voting.html#ReleaseVotes > [3] > https://repository.apache.org/content/repositories/orgapachemyfaces-1247/org/apache/myfaces/core/myfaces-core-assembly/ > [4] > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12354226 > > >
JSF Ajax Scripts
Hi, not really that interesting, but given that basically I only get a single bug every 3-4 months if at all for the jsf_ts codebase, I will lift the beta status of the companion project soon, so that myfaces has a non beta codebase for the jsf ajax scripts. (looks better, does not make any difference because both are in sync anyway) The status of the current ajax scripts is 4.0.2.beta.9 it will be 4.0.2 later on. For the foreseeable future I wont roll any new betas because I have not planned any big refactorings. As for 5.0 I have yet to check the api status, but the last time I checked, there were no API changes on the ajax side but that might change. If there is a big new change coming in for 5.0 then I will go back into beta version version status with a new 5.0.x version. I will finalize the version sometime next week on the node and myfaces side. Just wanted to drop the info, unless there are any major reasons to keep the ajax scripts in beta status, I will then roll a final 4.0.2 version as my time permits next week. Werner
[jira] [Resolved] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-4658.
--
Fix Version/s: 5.0.0
4.1.0-RC2
4.0.3
Resolution: Fixed
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
> Assignee: Werner Punz
>Priority: Major
> Fix For: 5.0.0, 4.1.0-RC2, 4.0.3
>
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833954#comment-17833954
]
Werner Punz commented on MYFACES-4658:
--
[~volosied] I have fixed the issue in the 3 attached pull requests (each for
each branch which uses the new codebase) please give it a shot, and if it works
for you then I can merge!
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
> Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz edited comment on MYFACES-4658 at 4/4/24 6:15 AM:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
Should be an easy fix, expect it later today!
was (Author: werpu):
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
> Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal
[jira] [Comment Edited] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz edited comment on MYFACES-4658 at 4/4/24 6:14 AM:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
was (Author: werpu):
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
{{}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
> Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = r
[jira] [Comment Edited] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz edited comment on MYFACES-4658 at 4/4/24 6:09 AM:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
boolean {{false}} if any scripts in the chain return {{{}false{}}}, otherwise
returns {{true}}
{{}}
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
was (Author: werpu):
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
> Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
>
[jira] [Comment Edited] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz edited comment on MYFACES-4658 at 4/4/24 6:08 AM:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
This test exposes the issue:
{code:java}
// code placeholder
it("chain must handle the true false return values correctly", function () {
let func1 = () => {
return true;
}
let func2 = () => {
return false;
}
let func3 = () => {
return undefined;
}
let func4 = () => {
return null;
}
let ret = faces.util.chain(this, {}, func1);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func2);
expect(ret).to.be.false;
ret = faces.util.chain(this, {}, func3);
expect(ret).to.be.true;
ret = faces.util.chain(this, {}, func4);
expect(ret).to.be.true;
}) {code}
was (Author: werpu):
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
>Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833828#comment-17833828
]
Werner Punz commented on MYFACES-4658:
--
Ok the discrepancy is indeed in the undefined handling, the spec states either
Here is the spec on this issue:
A varargs function that invokes an arbitrary number of scripts. If any script
in the chain returns false, the chain is short-circuited and subsequent scripts
are not invoked. Any number of scripts may specified after the {{event}}
argument.
So the old code is correct the new code is wrong here!
I will make a fix for it including a test!
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
> Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4658) faces.util.chain behavior changed
[
https://issues.apache.org/jira/browse/MYFACES-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17833668#comment-17833668
]
Werner Punz commented on MYFACES-4658:
--
Yes I will take care of it. I need to compare this with the spec as well!
Probably a slight deviation from the spec I have introduced here with my
rewrite!
Should be easy to fix!
> faces.util.chain behavior changed
> -
>
> Key: MYFACES-4658
> URL: https://issues.apache.org/jira/browse/MYFACES-4658
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.2
>Reporter: Volodymyr Siedlecki
> Assignee: Werner Punz
>Priority: Major
>
> Given the following generated HTML, an alert will occur. If you click OK, it
> will perform an action on a backing bean. However, if you cancel, it should
> not.
> {code:java}
> {code}
> On Faces 3.0, if cancel is pressed, then the backing bean is not invoked. On
> Faces 4.0, however, pressing cancel *does* invoke the bean.
> Faces 3.0:
> jsf.util.chain snippet:
> {noformat}
> if (FUNC == typeof arguments[cnt]) {
> ret = arguments[cnt].call(source, event);
> } else {
> //either a function or a string can be passed in case of a
> string we have to wrap it into another function
> ret = new Function("event", arguments[cnt]).call(source,
> event);
> }
> //now if one function returns false in between we stop the
> execution of the cycle
> //here, note we do a strong comparison here to avoid constructs
> like 'false' or null triggering
> if (ret === false /*undefined check implicitly done here by using
> a strong compare*/) {
> return false;
> }
> }{noformat}
> Faces 4.0:
> {noformat}
> function chain(source, event, ...funcs) {
> // we can use our lazy stream each functionality to run our chain
> here.
> // by passing a boolean as return value into the onElem call
> // we can stop early at the first false, just like the spec requests
> let ret;
> funcs.every(func => {
> let returnVal = resolveAndExecute(source, event, func);
> if (returnVal !== false) {
> ret = returnVal;
> }
> return returnVal !== false;
> });
> return ret;
> }{noformat}
> It looks like conditions changed here? "ret === false" became "returnVal !==
> false" ? If cancel is pressed, false is returned, which means the chain
> function returns false in 3.0. In faces 4.0, ret is never set (due to the
> new condition), so undefined (ret) is returned now instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [VOTE] Release Tobago 2.5.1
+1 Werner Am Do., 7. März 2024 um 10:23 Uhr schrieb Henning Nöth < henning.no...@irian.eu>: > Hello, > > I've fixed the issue with the "forceVerticalScrollbar" attribute and > want to start another vote for a Tobago 2.5.1 release. > > Changes since last release are: > * fix: DuplicateIdException with TabGroup navigation Menu > * fix: Sheet column header doesn't align with column content > > This is a PATCH release with backwards-compatible bug fixes. > > For a detail list please consult the release notes at: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273=12353364 > > The version is available at the staging repository (Nexus) at: > https://repository.apache.org/content/repositories/orgapachemyfaces-1246/ > > Source (sha-256 > 41074d8c833f711fbc468bc560c490f3ee5ed2dac2dd4b6193395e0af5e07a65): > > https://repository.apache.org/content/repositories/orgapachemyfaces-1246/org/apache/myfaces/tobago/tobago/2.5.1/tobago-2.5.1-source-release.zip > > > Please vote now! (The vote is open for 72h.) > > [ ] +1 > [ ] +0 > [ ] -1 > > Regards, > Henning >
Re: [VOTE] Release Tobago 2.5.1
+1 Am Mo., 4. März 2024 um 10:12 Uhr schrieb Henning Nöth < henning.no...@irian.eu>: > Hello, > > we would like to release Tobago 2.5.1. > > Changes since last release are: > * fix: DuplicateIdException with TabGroup navigation Menu > * fix: Sheet column header doesn't align with column content > > This is a PATCH release with backwards-compatible bug fixes. > > For a detail list please consult the release notes at: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273=12353364 > > The version is available at the staging repository (Nexus) at: > https://repository.apache.org/content/repositories/orgapachemyfaces-1245/ > > Source (sha-256 > 9b2bff2aa63c197bec10b5ac03cb6a76241b72c857ab6380b95e4a7cde9450ce): > > https://repository.apache.org/content/repositories/orgapachemyfaces-1245/org/apache/myfaces/tobago/tobago/2.5.1/tobago-2.5.1-source-release.zip > > > Please vote now! (The vote is open for 72h.) > > [ ] +1 > [ ] +0 > [ ] -1 > > Regards, > Henning >
Re: [VOTE] Release of MyFaces Core 4.1.0-RC1
+1, good job Werner Am Fr., 26. Jan. 2024 um 07:47 Uhr schrieb Bernd Bohmann : > Hers is my +1 > > Regards > > Bernd > > Paul Nicolucci schrieb am Do., 25. Jan. 2024, > 13:55: > >> +1 >> >> Thanks, >> >> Paul Nicolucci >> >> On Thu, Jan 25, 2024 at 7:38 AM Thomas Andraschko < >> andraschko.tho...@gmail.com> wrote: >> >>> +1 >>> >>> Am Mi., 24. Jan. 2024 um 22:45 Uhr schrieb Volodymyr Siedlecki < >>> volos...@apache.org>: >>> I tested an app with the RC1 jars and it ran fine. I'll do further testing with it once it's released (such as the TCK). Here's my +1 as well. On 2024/01/24 21:29:14 Melloware Inc wrote: > +1 from me! > > On Wed, Jan 24, 2024 at 3:50 PM Volodymyr Siedlecki < volos...@apache.org> > wrote: > > > Hello, again. > > > > Please review the new RC1 jars: > > https://repository.apache.org/content/repositories/orgapachemyfaces-1242/org/apache/myfaces/core/ > > > > myfaces-core-module-4.1.0-RC1 Tag: > > https://github.com/apache/myfaces/releases/tag/myfaces-core-module-4.1.0-RC1 > > > > Thanks, > > > > Volodymyr > > > > On 2024/01/24 19:54:52 Volodymyr Siedlecki wrote: > > > I found a mistake -- let me re-stage. > > > > > > I dropped > > https://repository.apache.org/content/repositories/orgapachemyfaces-1241/org/apache/myfaces/core/ > > and the jars aren't available anymore. > > > > > > On 2024/01/24 19:16:53 Volodymyr Siedlecki wrote: > > > > Hi, > > > > > > > > I was running the needed tasks to get the 4.1.0-RC1 release of Apache > > > > MyFaces core out. > > > > > > > > Please note that this vote concerns all of the following parts: > > > >1. Maven artifact group “org.apache.myfaces.core” v4.1.0-RC1 [1] > > > > > > > > The artifacts were deployed on nexus repo [1] for binary and source > > > > packages. > > > > > > > > The release notes could be found at [4]. > > > > > > > > The japicmp tool shows some binary incompatibilities with 4.1.0-RC1 > > and the > > > > jakarta.faces-api-4.1.0-M1.jar. Please take a look at the attached > > > > results.html. > > > > > > > > This release has not yet been run against the TCK. > > > > > > > > Please take a look at the “4.1.0-RC1" artifacts and vote! (see [3]) > > > > > > > > Please note: This vote is “majority approval” with a minimum of three > > +1 > > > > votes (see [2]). > > > > > > > > > > > > [ ] +1 for community members who have reviewed the bits > > > > [ ] +0 > > > > [ ] -1 for fatal flaws that should cause these bits not to be > > released, and > > > > why. > > > > > > > > > > > > Thanks, > > > > > > > > Volodymyr > > > > > > > > [1] > > > > > > https://repository.apache.org/content/repositories/orgapachemyfaces-1241/org/apache/myfaces/core/ > > > > [2] http://www.apache.org/foundation/voting.html#ReleaseVotes > > > > [3] > > > > > > https://repository.apache.org/content/repositories/orgapachemyfaces-1241/org/apache/myfaces/core/myfaces-core-assembly/ > > > > [4] > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600=12353454 > > > > > > > > > > > > -- > == > Melloware > melloware...@gmail.com > http://melloware.com > == > >>>
Re: [VOTE] Release Tobago 6.2.0 and Tobago 5.10.0
+1 Werner Am Di., 23. Jan. 2024 um 09:16 Uhr schrieb Bernd Bohmann : > Here is my > > +1 > > Regards > > Bernd > > Henning Nöth schrieb am Mo., 22. Jan. 2024, > 14:15: > >> Hello, >> >> we would like to release: >> * Tobago 6.2.0 >> * Tobago 5.10.0 >> >> The artifacts were deployed on nexus repository for binary and source >> packages: >> * Tobago 6.2.0 [1] >> * Tobago 5.10.0 [1] >> >> The release notes are in Jira: >> * Tobago 6.2.0 [2] >> * Tobago 5.10.0 [3] >> >> The artifacts are available at the staging repository (Nexus) at: >> * Tobago 6.2.0 [4] (sha-256 >> ba72c8d3aae905779bd13567eb4f65eba9b340b5af2fa8645eb05991a0249e32) >> * Tobago 5.10.0 [5] (sha-256 >> c35090d3154c304ab67adfece69e5b545ee5263a7a06be3f00d8b915279c747a) >> >> Please vote now! (The vote is open for 72h.) >> >> [ ] +1 >> [ ] +0 >> [ ] -1 >> >> Regards, >> Henning >> >> [1] >> https://repository.apache.org/content/repositories/orgapachemyfaces-1239/ >> [2] >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273=12353966 >> [3] >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273=12353965 >> [4] >> >> https://repository.apache.org/content/repositories/orgapachemyfaces-1239/org/apache/myfaces/tobago/tobago/6.2.0/tobago-6.2.0-source-release.zip >> [5] >> >> https://repository.apache.org/content/repositories/orgapachemyfaces-1239/org/apache/myfaces/tobago/tobago/5.10.0/tobago-5.10.0-source-release.zip >> >
AI for documentation comments
I know I will open a can of works with this discussion here. Given I toyed around with the Jetbrains ai a little bit, what is the general opinion on using ai to generate comments. I am aware that using ai for generating standard code is mostly a no go because of unresolved copyright issues where foreign code can leak in, but generating comments? Any idea on this, maybe I should ask this in legal. Not that I want to do it for ASF code, but I would be interested what everyone thinks of this! Werner
Re: [VOTE] Release Tobago 6.1.0 and Tobago 5.9.0
+1 Werner Am Mi., 29. Nov. 2023 um 16:20 Uhr schrieb Bernd Bohmann : > Here is my > > +1 > > Regards > > Bernd > > Henning Nöth schrieb am Di., 28. Nov. 2023, > 17:18: > >> Hello, >> >> we would like to release: >> * Tobago 6.1.0 >> * Tobago 5.9.0 >> >> The artifacts were deployed on nexus repository for binary and source >> packages: >> * Tobago 6.1.0 [1] >> * Tobago 5.9.0 [1] >> >> The release notes are in Jira: >> * Tobago 6.1.0 [2] >> * Tobago 5.9.0 [3] >> >> The artifacts are available at the staging repository (Nexus) at: >> * Tobago 6.1.0 [4] (sha-256 >> 0b80ef319aceda65cfbfc1bf9e9c6f8b13b43f11e783e584c7bfc6e1eb6f36e5) >> * Tobago 5.9.0 [5] (sha-256 >> 0840ac0689ee41d41a3af78fd2b86d0b4acfe50e934dc84318639a8a6fa30930) >> >> Please vote now! (The vote is open for 72h.) >> >> [ ] +1 >> [ ] +0 >> [ ] -1 >> >> Regards, >> Henning >> >> [1] >> https://repository.apache.org/content/repositories/orgapachemyfaces-1238 >> [2] >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273=12353821 >> [3] >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273=12353822 >> [4] >> >> https://repository.apache.org/content/repositories/orgapachemyfaces-1238/org/apache/myfaces/tobago/tobago/6.1.0/tobago-6.1.0-source-release.zip >> [5] >> >> https://repository.apache.org/content/repositories/orgapachemyfaces-1238/org/apache/myfaces/tobago/tobago/5.9.0/tobago-5.9.0-source-release.zip >> >
[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=17789435#comment-17789435
]
Werner Punz commented on MYFACES-4606:
--
Yes, sorry to answer so late, has been resolved this week!
> 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] [Resolved] (MYFACES-4640) Smaller issues with the appendIussingElements code discovered by Tobago Tests
[ https://issues.apache.org/jira/browse/MYFACES-4640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-4640. -- Fix Version/s: 4.0.2 4.1.0 5.0.0 Resolution: Fixed Resolved by merge of the latest codebase from jsf_ts! > Smaller issues with the appendIussingElements code discovered by Tobago Tests > - > > Key: MYFACES-4640 > URL: https://issues.apache.org/jira/browse/MYFACES-4640 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 4.0.0, 4.0.1, 5.0.0 > Reporter: Werner Punz > Assignee: Werner Punz >Priority: Major > Fix For: 4.0.2, 4.1.0, 5.0.0 > > > The Tobago people have discovered several smaller issues regards the new > appendIssuingItem code where the item was incorrectly added or with a wrong > value. > This is fixed now and fortified with unit tests testing the scenarii! > Tobago runs now with jsf.js_next_gen@4.0.2-beta.8 so I will move this version > back into myfaces! > The fixes from tobago already have pending pull requests for 3.0 and 2.3-next -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MYFACES-4640) Smaller issues with the appendIussingElements code discovered by Tobag Usecases
Werner Punz created MYFACES-4640: Summary: Smaller issues with the appendIussingElements code discovered by Tobag Usecases Key: MYFACES-4640 URL: https://issues.apache.org/jira/browse/MYFACES-4640 Project: MyFaces Core Issue Type: Bug Affects Versions: 4.0.1, 4.0.0, 5.0.0 Reporter: Werner Punz The Tobago people have discovered several smaller issues regards the new appendIssuingItem code where the item was incorrectly added or with a wrong value. This is fixed now and fortified with unit tests testing the scenarii! Tobago runs now with jsf.js_next_gen@4.0.2-beta.8 so I will move this version back into myfaces! The fixes from tobago already have pending pull requests for 3.0 and 2.3-next -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4638) Inputs submitted by AJAX loose all content beginning with ampersand ("&") characters
[
https://issues.apache.org/jira/browse/MYFACES-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-4638.
--
Resolution: Fixed
> Inputs submitted by AJAX loose all content beginning with ampersand ("&")
> characters
>
>
> Key: MYFACES-4638
> URL: https://issues.apache.org/jira/browse/MYFACES-4638
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0
>Reporter: Andreas Osterburg
>Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
> Attachments: patch-FileUtils.txt, test.xhtml
>
>
> When submitting input fields with AJAX the ampersand "&" character is not
> handled properly on client side.
> A test case ist attached. Just submitting the form works as expected,
> submitting by AJAX
> fails if input contains "&"-signs, like "foo".
> It tracked this down to the function _decodeEncodedValues_ in
> {_}FileUtils.ts{_}. There happens a
> decode of the current ViewState in URI-encoded format.
> Basically the source of the issue is that the input string (in
> "{_}encoded"){_} is processed in wrong order.
> Currently it is first URI-decoded an then splitted by ampersands ("&"). It
> has to be in
> reverse order, since the payload may contain ampersands, which are
> URI-encoded by "%26".
> A small working patch for demonstration is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4638) Inputs submitted by AJAX loose all content beginning with ampersand ("&") characters
[
https://issues.apache.org/jira/browse/MYFACES-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784108#comment-17784108
]
Werner Punz commented on MYFACES-4638:
--
Fixed
> Inputs submitted by AJAX loose all content beginning with ampersand ("&")
> characters
>
>
> Key: MYFACES-4638
> URL: https://issues.apache.org/jira/browse/MYFACES-4638
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0
>Reporter: Andreas Osterburg
>Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
> Attachments: patch-FileUtils.txt, test.xhtml
>
>
> When submitting input fields with AJAX the ampersand "&" character is not
> handled properly on client side.
> A test case ist attached. Just submitting the form works as expected,
> submitting by AJAX
> fails if input contains "&"-signs, like "foo".
> It tracked this down to the function _decodeEncodedValues_ in
> {_}FileUtils.ts{_}. There happens a
> decode of the current ViewState in URI-encoded format.
> Basically the source of the issue is that the input string (in
> "{_}encoded"){_} is processed in wrong order.
> Currently it is first URI-decoded an then splitted by ampersands ("&"). It
> has to be in
> reverse order, since the payload may contain ampersands, which are
> URI-encoded by "%26".
> A small working patch for demonstration is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4638) Inputs submitted by AJAX loose all content beginning with ampersand ("&") characters
[
https://issues.apache.org/jira/browse/MYFACES-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784088#comment-17784088
]
Werner Punz commented on MYFACES-4638:
--
Seems like the fix is not entirely complete I am getting a cut off part after
the & in my unit test, I need to debug this out!
> Inputs submitted by AJAX loose all content beginning with ampersand ("&")
> characters
>
>
> Key: MYFACES-4638
> URL: https://issues.apache.org/jira/browse/MYFACES-4638
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0
>Reporter: Andreas Osterburg
>Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
> Attachments: patch-FileUtils.txt, test.xhtml
>
>
> When submitting input fields with AJAX the ampersand "&" character is not
> handled properly on client side.
> A test case ist attached. Just submitting the form works as expected,
> submitting by AJAX
> fails if input contains "&"-signs, like "foo".
> It tracked this down to the function _decodeEncodedValues_ in
> {_}FileUtils.ts{_}. There happens a
> decode of the current ViewState in URI-encoded format.
> Basically the source of the issue is that the input string (in
> "{_}encoded"){_} is processed in wrong order.
> Currently it is first URI-decoded an then splitted by ampersands ("&"). It
> has to be in
> reverse order, since the payload may contain ampersands, which are
> URI-encoded by "%26".
> A small working patch for demonstration is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4638) Inputs submitted by AJAX loose all content beginning with ampersand ("&") characters
[
https://issues.apache.org/jira/browse/MYFACES-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784083#comment-17784083
]
Werner Punz edited comment on MYFACES-4638 at 11/8/23 2:54 PM:
---
Patch works, my existing tests pass, but I want to add a dedicated test for
this exact usecase in my unit tests!
So be patient, I will issue a merge request later today for 4 +
PS: Thanks for debugging this out, it was really helpful!
was (Author: werpu):
Patch works, my existing tests pass, but I want to add a dedicated test for
this exact usecase in my unit tests!
So be patient, I will issue a merge request later today for 4 +
> Inputs submitted by AJAX loose all content beginning with ampersand ("&")
> characters
>
>
> Key: MYFACES-4638
> URL: https://issues.apache.org/jira/browse/MYFACES-4638
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0
>Reporter: Andreas Osterburg
>Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
> Attachments: patch-FileUtils.txt, test.xhtml
>
>
> When submitting input fields with AJAX the ampersand "&" character is not
> handled properly on client side.
> A test case ist attached. Just submitting the form works as expected,
> submitting by AJAX
> fails if input contains "&"-signs, like "foo".
> It tracked this down to the function _decodeEncodedValues_ in
> {_}FileUtils.ts{_}. There happens a
> decode of the current ViewState in URI-encoded format.
> Basically the source of the issue is that the input string (in
> "{_}encoded"){_} is processed in wrong order.
> Currently it is first URI-decoded an then splitted by ampersands ("&"). It
> has to be in
> reverse order, since the payload may contain ampersands, which are
> URI-encoded by "%26".
> A small working patch for demonstration is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4638) Inputs submitted by AJAX loose all content beginning with ampersand ("&") characters
[
https://issues.apache.org/jira/browse/MYFACES-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17784083#comment-17784083
]
Werner Punz commented on MYFACES-4638:
--
Patch works, my existing tests pass, but I want to add a dedicated test for
this exact usecase in my unit tests!
So be patient, I will issue a merge request later today for 4 +
> Inputs submitted by AJAX loose all content beginning with ampersand ("&")
> characters
>
>
> Key: MYFACES-4638
> URL: https://issues.apache.org/jira/browse/MYFACES-4638
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0
>Reporter: Andreas Osterburg
>Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
> Attachments: patch-FileUtils.txt, test.xhtml
>
>
> When submitting input fields with AJAX the ampersand "&" character is not
> handled properly on client side.
> A test case ist attached. Just submitting the form works as expected,
> submitting by AJAX
> fails if input contains "&"-signs, like "foo".
> It tracked this down to the function _decodeEncodedValues_ in
> {_}FileUtils.ts{_}. There happens a
> decode of the current ViewState in URI-encoded format.
> Basically the source of the issue is that the input string (in
> "{_}encoded"){_} is processed in wrong order.
> Currently it is first URI-decoded an then splitted by ampersands ("&"). It
> has to be in
> reverse order, since the payload may contain ampersands, which are
> URI-encoded by "%26".
> A small working patch for demonstration is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4638) Inputs submitted by AJAX loose all content beginning with ampersand ("&") characters
[
https://issues.apache.org/jira/browse/MYFACES-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17783992#comment-17783992
]
Werner Punz commented on MYFACES-4638:
--
Thanks I will take over this!
> Inputs submitted by AJAX loose all content beginning with ampersand ("&")
> characters
>
>
> Key: MYFACES-4638
> URL: https://issues.apache.org/jira/browse/MYFACES-4638
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0
>Reporter: Andreas Osterburg
>Assignee: Werner Punz
>Priority: Major
> Fix For: 4.0.2, 4.1.0, 5.0.0
>
> Attachments: patch-FileUtils.txt, test.xhtml
>
>
> When submitting input fields with AJAX the ampersand "&" character is not
> handled properly on client side.
> A test case ist attached. Just submitting the form works as expected,
> submitting by AJAX
> fails if input contains "&"-signs, like "foo".
> It tracked this down to the function _decodeEncodedValues_ in
> {_}FileUtils.ts{_}. There happens a
> decode of the current ViewState in URI-encoded format.
> Basically the source of the issue is that the input string (in
> "{_}encoded"){_} is processed in wrong order.
> Currently it is first URI-decoded an then splitted by ampersands ("&"). It
> has to be in
> reverse order, since the payload may contain ampersands, which are
> URI-encoded by "%26".
> A small working patch for demonstration is attached.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [VOTE] Release Tobago 6.0.0 and Tobago 5.8.0
+1 Werner Am Mi., 8. Nov. 2023 um 07:25 Uhr schrieb Bernd Bohmann : > Here is my +1 > > Regards > > Bernd > > On Mon, Nov 6, 2023 at 4:07 PM Henning Nöth > wrote: > >> Hello, >> >> we would like to release: >> * Tobago 6.0.0 >> * Tobago 5.8.0 >> >> The artifacts were deployed on nexus repository for binary and source >> packages: >> * Tobago 6.0.0 [1] >> * Tobago 5.8.0 [2] >> >> The release notes are in Jira: >> * Tobago 6.0.0 [3] >> * Tobago 5.8.0 [4] >> >> The artifacts are available at the staging repository (Nexus) at: >> * Tobago 6.0.0 [5] (sha-256 >> 90a88835788fb30e78ee38808549c549f6a6ebf05300fe1730f3d23b810a4bba) >> * Tobago 5.8.0 [6] (sha-256 >> 33239017981ccb09ed1498e98fc3f296927de26ffedacaad706ffe28a6d3328c) >> >> Please vote now! (The vote is open for 72h.) >> >> [ ] +1 >> [ ] +0 >> [ ] -1 >> >> Regards, >> Henning >> >> [1] >> https://repository.apache.org/content/repositories/orgapachemyfaces-1236 >> [2] >> https://repository.apache.org/content/repositories/orgapachemyfaces-1237 >> [3] >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273=12350675 >> [4] >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273=12353182 >> [5] >> >> https://repository.apache.org/content/repositories/orgapachemyfaces-1236/org/apache/myfaces/tobago/tobago/6.0.0/tobago-6.0.0-source-release.zip >> [6] >> >> https://repository.apache.org/content/repositories/orgapachemyfaces-1237/org/apache/myfaces/tobago/tobago/5.8.0/tobago-5.8.0-source-release.zip >> >
[jira] [Commented] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782508#comment-17782508
]
Werner Punz commented on MYFACES-4636:
--
No I dont think so, but we have to double check this!
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Fix For: 3.0.3, 4.0.2, 2.3-next-M9, 4.1.0, 5.0.0
>
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> //<![CDATA[
> function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782455#comment-17782455
]
Werner Punz edited comment on MYFACES-4636 at 11/3/23 8:18 AM:
---
Looks ok to me, the test reconfirms the result anyway, I wonder why the +colon
was added, probably a misunderstanding of the mechanism, but we will see!
This might not only affect 2.3 but also the other branches, this needs to be
reconfirmed!
Thanks for fixing this [~tandraschko]
was (Author: werpu):
Looks ok to me, the test reconfirms the result anyway, I wonder why the +colon
was added, probably a misunderstanding of the mechanism, but we will see!
Thanks for fixing this [~tandraschko]
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Fix For: 4.0.2, 2.3-next-M9, 4.1.0, 5.0.0
>
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> //<![CDATA[
> function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782455#comment-17782455
]
Werner Punz commented on MYFACES-4636:
--
Looks ok to me, the test reconfirms the result anyway, I wonder why the +colon
was added, probably a misunderstanding of the mechanism, but we will see!
Thanks for fixing this [~tandraschko]
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Fix For: 4.0.2, 2.3-next-M9, 4.1.0, 5.0.0
>
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> //<![CDATA[
> function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781339#comment-17781339
]
Werner Punz edited comment on MYFACES-4636 at 10/31/23 12:52 PM:
-
This seems to be an issue in the java renderer, the analysis is correct, the
chain function is wrongly constructed!
a comma is missing after testJs! Afair when I did the 4.0 javascripts I noticed
that the spec passing the params has changed slightly, i adapted the code, you
now can and should pass params maps via params: instead of just
passing the map!
I left the way how we did it in the past open, but it seems there was a slight
mistake in the changes in the java renderer adapting to the spec conform api!
was (Author: werpu):
This seems to be an issue in the java renderer, the analysis is correct, the
chain function is wrongly constructed!
a comma is missing after testJs!
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> //<![CDATA[
> function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781339#comment-17781339
]
Werner Punz edited comment on MYFACES-4636 at 10/31/23 12:50 PM:
-
This seems to be an issue in the java renderer, the analysis is correct, the
chain function is wrongly constructed!
a comma is missing after testJs!
was (Author: werpu):
This seems to be an issue in the java renderer, the analysis is correct, the
chain function is wrongly constructed!
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> //<![CDATA[
> function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781339#comment-17781339
]
Werner Punz edited comment on MYFACES-4636 at 10/31/23 12:49 PM:
-
This seems to be an issue in the java renderer, the analysis is correct, the
chain function is wrongly constructed!
was (Author: werpu):
This seems to be an issue in the java renderer, this is not syntatically
correct, onevent wants a function. There seems to be something going wrong with
the params rendering onEvent: testJsParams is definitely wrong here!
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> //<![CDATA[
> function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4636) Using f:param + f:ajax onvent results in an error
[
https://issues.apache.org/jira/browse/MYFACES-4636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781339#comment-17781339
]
Werner Punz commented on MYFACES-4636:
--
This seems to be an issue in the java renderer, this is not syntatically
correct, onevent wants a function. There seems to be something going wrong with
the params rendering onEvent: testJsParams is definitely wrong here!
> Using f:param + f:ajax onvent results in an error
> -
>
> Key: MYFACES-4636
> URL: https://issues.apache.org/jira/browse/MYFACES-4636
> Project: MyFaces Core
> Issue Type: Bug
>Affects Versions: 2.3-next-M8
>Reporter: Vitaly Sidorov
>Priority: Major
> Attachments: sample.zip
>
>
> *Steps to reproduce:*
> - create xhtml with f:param and f:ajax onevent like this:
>
> {code:html}
>
>
>
>
> execute="@this"
> onevent="testJs">
>
>
>
>
> //<![CDATA[
> function testJs(data) {
> if (data.status === 'success') {
> alert("Success click")
> }
> }
> //]]>
>
> {code}
>
> - click on "Click me"
> - get an error in the console: "{color:#FF}Uncaught SyntaxError:
> Unexpected token ':' (at index.xhtml:9:868){color}"
> *The reason:*
> Generated page code by M7 build:
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJs,'var1':'NEW
> VALUE'})}); return false;
> {code}
> Generated page code by M8 build with *bad JS* (look at {*}testJsparams{*}):
> {code:javascript}
> jsf.util.chain(this,
> event,function(event){myfaces.ab(this,event,'click','j_id_i','',{'onevent':testJsparams:{'var1':'NEW
> VALUE'}})}); return false;
> {code}
> *I've attached an archive with an example.*
--
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=17775044#comment-17775044
]
Werner Punz commented on MYFACES-4606:
--
Pull request opened [https://github.com/apache/myfaces/pull/630]
you can check it, I will merge on monday, unless someone else wants to do it!
> 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=17774670#comment-17774670
]
Werner Punz commented on MYFACES-4606:
--
Ok I checked the old code, the old code does not have this problem because only
buttons and submits are appended (we might add hrefs in the long run if
requested)
So I can roll a new jsf_ts release tomorrow and pull the changes in.
The fix is more or less that I basically do not append a checkbox or radio
button as issuing element if it is unchecked (hence the value is not appended
then)
Since the mechanism is needed mostly for buttons anyway (and hrefs), it should
be ok to have this behavior!
> 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=17774160#comment-17774160
]
Werner Punz commented on MYFACES-4606:
--
I have it working for the new codebase, the old one I have not had time to fix
it, will be done by end of the week!
> 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] (TOBAGO-2250) Ajax request adds a new meta tag
[
https://issues.apache.org/jira/browse/TOBAGO-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772509#comment-17772509
]
Werner Punz edited comment on TOBAGO-2250 at 10/6/23 10:03 AM:
---
Ah ok, thanks for the clarification.
Yes this is then definitely an issue with the jsf.js codebase!
I need to check the update code, we have something in the update head to deal
with this, I guess we need to apply the same algorithm, did not have it on the
radar that meta tags also can be in update resource!
was (Author: werpu):
Ah ok, thanks for the clarification.
Yes this is then definitely an issue with the jsf.js codebase!
> Ajax request adds a new meta tag
>
>
> Key: TOBAGO-2250
> URL: https://issues.apache.org/jira/browse/TOBAGO-2250
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 6.0.0-beta-1
>Reporter: Henning Nöth
>Assignee: Henning Nöth
>Priority: Critical
>
> With every ajax request, a
> {code:xml}
>
> {code}
> tag is added to .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TOBAGO-2250) Ajax request adds a new meta tag
[
https://issues.apache.org/jira/browse/TOBAGO-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772509#comment-17772509
]
Werner Punz commented on TOBAGO-2250:
-
Ah ok, thanks for the clarification.
Yes this is then definitely an issue with the jsf.js codebase!
> Ajax request adds a new meta tag
>
>
> Key: TOBAGO-2250
> URL: https://issues.apache.org/jira/browse/TOBAGO-2250
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 6.0.0-beta-1
>Reporter: Henning Nöth
>Assignee: Henning Nöth
>Priority: Critical
>
> With every ajax request, a
> {code:xml}
>
> {code}
> tag is added to .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TOBAGO-2250) Ajax request adds a new meta tag
[
https://issues.apache.org/jira/browse/TOBAGO-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17772502#comment-17772502
]
Werner Punz commented on TOBAGO-2250:
-
jsf.js_next_gen does not really add any meta tags, but I can check my js code,
this is more likely on the java side.
> Ajax request adds a new meta tag
>
>
> Key: TOBAGO-2250
> URL: https://issues.apache.org/jira/browse/TOBAGO-2250
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Core
>Affects Versions: 6.0.0-beta-1
>Reporter: Henning Nöth
>Assignee: Henning Nöth
>Priority: Critical
>
> With every ajax request, a
> {code:xml}
>
> {code}
> tag is added to .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (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:all-tabpanel
]
Werner Punz reopened MYFACES-4606:
--
> 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-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=17772292#comment-17772292
]
Werner Punz edited comment on MYFACES-4606 at 10/5/23 4:33 PM:
---
Working on it, only checkboxes and radio buttons are affected by this problem.
I will need to roll another small jsf_ts bugfix script for it, the fix is
minor, I just check the type and exclude the appendIssuingItem in this case.
Given that the behavior is needed for links or buttons only anyway, I can live
with this small inconsistency!
Also the old branches need to be checked. So expect the final fix for all
affected branches next week!
was (Author: werpu):
Working on it, only checkboxes and radio buttons are affected by this problem.
I will need to roll another small jsf_ts bugfix script for it, the fix is
minor, I just check the type and exclude the appendIssuingItem in this case.
Given that the behavior is needed for links or buttons only anyway, I can live
with this small inconsistency!
> 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=17772292#comment-17772292
]
Werner Punz commented on MYFACES-4606:
--
Working on it, only checkboxes and radio buttons are affected by this problem.
I will need to roll another small jsf_ts bugfix script for it, the fix is
minor, I just check the type and exclude the appendIssuingItem in this case.
Given that the behavior is needed for links or buttons only anyway, I can live
with this small inconsistency!
> 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] [Resolved] (MYFACES-4630) Compressed Files Necessary in 4.0 API?
[ https://issues.apache.org/jira/browse/MYFACES-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-4630. -- Fix Version/s: 4.0.2 Resolution: Fixed merge pull request form [~volosied] > 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 > Fix For: 4.0.2 > > > 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 12:42 PM: 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 webpack file by taking out the plugins which produce them! 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 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-4536) PartialResponseWriter: Do no wrap the writer
[
https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17771458#comment-17771458
]
Werner Punz edited comment on MYFACES-4536 at 10/3/23 12:21 PM:
Ok I will alter my test accordingly, lets see!
Still passing:
[https://gist.github.com/werpu/93e05f0cba260be33349afec8564c9d9]
Is producing:
{code:java}
{code}
So no swallowed eval! So, neither the partial response writer nor the
HTMLResponseWriterImpl produce this problem (those are the ones which are in
the chain)
was (Author: werpu):
Ok I will alter my test accordingly, lets see!
Still passing:
[https://gist.github.com/werpu/93e05f0cba260be33349afec8564c9d9]
Is producing:
{code:java}
{code}
So no swallowed eval!
> 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=17771458#comment-17771458
]
Werner Punz edited comment on MYFACES-4536 at 10/3/23 12:18 PM:
Ok I will alter my test accordingly, lets see!
Still passing:
[https://gist.github.com/werpu/93e05f0cba260be33349afec8564c9d9]
Is producing:
{code:java}
{code}
So no swallowed eval!
was (Author: werpu):
Ok I will alter my test accordingly, lets see!
> 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=17771458#comment-17771458
]
Werner Punz commented on MYFACES-4536:
--
Ok I will alter my test accordingly, lets see!
> 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: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] [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] [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] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
<pre>
[
<a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165">https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165</a>
]
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
<![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 when 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>
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\"
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
<pre>
[
<a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165">https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165</a>
]
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> {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.
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: <a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536">https://issues.apache.org/jira/browse/MYFACES-4536</a>
> 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
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
<pre>
[
<a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165">https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165</a>
]
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: <a rel="nofollow" href="htt
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
<pre>
[
<a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165">https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165</a>
]
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
<![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.
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!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: <a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536">https://issues.apache.org/jira/browse/MYFACES-4536</a>
> 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: <a rel="nofollow" href="https://github.com/primefaces/primefaces/issues/9518">https://github.com/primefaces/primefaces/issues/9518</a>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
</pre>
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
<pre>
[
<a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165">https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165</a>
]
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
<![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!
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!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: <a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536">https://issues.apache.org/jira/browse/MYFACES-4536</a>
> 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: <a rel="nofollow" href="https://github.com/primefaces/primefaces/issues/9518">https://github.com/primefaces/primefaces/issues/9518</a>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
</pre>
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
<pre>
[
<a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165">https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165</a>
]
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
<![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.
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!
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: <a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536">https://issues.apache.org/jira/browse/MYFACES-4536</a>
> 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: <a rel="nofollow" href="https://github.com/primefaces/primefaces/issues/9518">https://github.com/primefaces/primefaces/issues/9518</a>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
</pre>
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
<pre>
[
<a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165">https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165</a>
]
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
<![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!
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.
> PartialResponseWriter: Do no wrap the writer
>
>
> Key: MYFACES-4536
> URL: <a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536">https://issues.apache.org/jira/browse/MYFACES-4536</a>
> 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: <a rel="nofollow" href="https://github.com/primefaces/primefaces/issues/9518">https://github.com/primefaces/primefaces/issues/9518</a>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
</pre>
[jira] [Comment Edited] (MYFACES-4536) PartialResponseWriter: Do no wrap the writer
<pre>
[
<a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165">https://issues.apache.org/jira/browse/MYFACES-4536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17771165#comment-17771165</a>
]
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: <a rel="nofollow" href="https://issues.apache.org/jira/browse/MYFACES-4536">https://issues.apache.org/jira/browse/MYFACES-4536</a>
> 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: <a rel="nofollow" href="https://github.com/primefaces/primefaces/issues/9518">https://github.com/primefaces/primefaces/issues/9518</a>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
</pre>
[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=17770196#comment-17770196
]
Werner Punz commented on MYFACES-4536:
--
Thanks I will tackle this now asap, sorry for the delay, I was bound by private
life and projects. I guess I will find time to start to work on it at the
weekend!
> 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: [VOTE] Release Tobago 6.0.0-beta-1 and checkstyle-rules 23
+1 Werner Am Do., 14. Sept. 2023 um 14:01 Uhr schrieb Henning Nöth < henning.no...@irian.eu>: > Hello, > > we would like to release: > * Tobago 6.0.0-beta-1 > * checkstyle-rules 23 > > The artifacts were deployed on nexus repository for binary and source > packages: > * Tobago 6.0.0-beta-1 [1] > * checkstyle-rules 23 [2] > > The release notes are in Jira: > * Tobago 6.0.0-beta-1 [3] > > The artifacts are available at the staging repository (Nexus) at: > > * Tobago 6.0.0-beta-1 [4] (sha-256 > 21ccc386e952c1b49db645be20cfc7fe2ad4535db06e6f29a89accc1d4720eef) > * checkstyle-rules 23 [5] (sha-256 > ea91bc31cb6b7e1bb7308e3baa765de520d2106975248ca74709df3501546ee9) > > Please vote now! (The vote is open for 72h.) > > [ ] +1 > [ ] +0 > [ ] -1 > > Regards, > > Henning > > [1] > https://repository.apache.org/content/repositories/orgapachemyfaces-1235 > [2] > https://repository.apache.org/content/repositories/orgapachemyfaces-1234 > [3] > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310273=12353634 > [4] > > https://repository.apache.org/content/repositories/orgapachemyfaces-1235/org/apache/myfaces/tobago/tobago/6.0.0-beta-1/tobago-6.0.0-beta-1-source-release.zip > [5] > > https://repository.apache.org/content/repositories/orgapachemyfaces-1234/org/apache/myfaces/buildtools/checkstyle-rules/23/checkstyle-rules-23-source-release.zip >
[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=17756573#comment-17756573 ] Werner Punz edited comment on MYFACES-4536 at 8/20/23 7:38 PM: --- 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. 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
[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=17756573#comment-17756573 ] Werner Punz edited comment on MYFACES-4536 at 8/20/23 7:38 PM: --- 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
[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=17756573#comment-17756573 ] Werner Punz edited comment on MYFACES-4536 at 8/20/23 7:38 PM: --- 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
[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=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
[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=17753335#comment-17753335
]
Werner Punz commented on MYFACES-4536:
--
I will have a look at this bug, the next few days. Might take a few days since
atm I only can work on myfaces in my sparetime, but I have it on my radar now!
> 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=17753332#comment-17753332
]
Werner Punz edited comment on MYFACES-4536 at 8/11/23 7:45 PM:
---
This is indeed a bug in myfaces, the response eval section is perfectly valid
within the spec!
It definitely should not be gone!
Good question where this happens, it basically can only happen within the
response writer!
I do not remember why the double buffering was added, this was a long time ago.
But it should not make a difference! So if it happens there it definitely is a
bug.
was (Author: werpu):
This is indeed a bug in myfaces, the response eval section is perfectly valid
within the spec!
It definitely should not be gone!
> 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=17753332#comment-17753332
]
Werner Punz commented on MYFACES-4536:
--
This is indeed a bug in myfaces, the response eval section is perfectly valid
within the spec!
It definitely should not be gone!
> 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] [Resolved] (MYFACES-4605) Cross form rending via ajax, form is missing ViewState
[ https://issues.apache.org/jira/browse/MYFACES-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-4605. -- Fix Version/s: 4.0.2 Resolution: Fixed 4.0.2 added because it fixes the identifier issue, that was the only thing which was incorrect on the client side, and the rest is not an error per se, but how the system behaves! > Cross form rending via ajax, form is missing ViewState > -- > > Key: MYFACES-4605 > URL: https://issues.apache.org/jira/browse/MYFACES-4605 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.1, 2.3.10 >Reporter: Joe Crichton > Assignee: Werner Punz >Priority: Major > Fix For: 2.3.11, 3.0.3, 4.0.2 > > Attachments: image-2023-06-20-21-22-50-593.png > > > Seems this is an old issue, which was presumably fixed for MyFaces in 2.2 as > discussed here > [https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm|https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm),] > and [https://github.com/jakartaee/faces/issues/790] > Using openliberty with jsf-3.0 feature still has this occurring. Using the > workaround outlined by the first link fixes the issue. I believe the same is > true for the jsf-2.3 feature as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-4610. -- Fix Version/s: 4.0.2 4.0.0 Resolution: Fixed > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 > Reporter: Werner Punz > Assignee: Werner Punz >Priority: Major > Fix For: 4.0.2, 4.0.0 > > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740879#comment-17740879 ] Werner Punz edited comment on MYFACES-4610 at 7/7/23 5:32 AM: -- The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently ) was (Author: werpu): The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently) > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 > Reporter: Werner Punz > Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740879#comment-17740879 ] Werner Punz edited comment on MYFACES-4610 at 7/7/23 5:32 AM: -- The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently https://issues.apache.org/jira/browse/MYFACES-4606) was (Author: werpu): The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently ) > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 > Reporter: Werner Punz > Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740879#comment-17740879 ] Werner Punz edited comment on MYFACES-4610 at 7/7/23 5:32 AM: -- The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently https://issues.apache.org/jira/browse/MYFACES-4605) was (Author: werpu): The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently https://issues.apache.org/jira/browse/MYFACES-4606) > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 > Reporter: Werner Punz > Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17740879#comment-17740879 ] Werner Punz commented on MYFACES-4610: -- The old code is not affected by it, I did the determination of the origin slightly different there in my fix, am not sure which approach is better, but for now the changes I will do in the old branches are just fixing the id issue so that it starts with a 1 instead of 0 in the identifier number postfix for hidden fields. (the second issue which was discussed recently) > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 > Reporter: Werner Punz > Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737968#comment-17737968 ] Werner Punz commented on MYFACES-4610: -- Pull request merged for main (Myfaces 4.0), other branches will follow the upcoming days > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 > Reporter: Werner Punz > Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4605) Cross form rending via ajax, form is missing ViewState
[ https://issues.apache.org/jira/browse/MYFACES-4605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737814#comment-17737814 ] Werner Punz commented on MYFACES-4605: -- Have issued a fix for the id :0 problem for myfaces 4.0 which will be merged today. Will issue a fix for the 2.x and 3.x branches later this week! > Cross form rending via ajax, form is missing ViewState > -- > > Key: MYFACES-4605 > URL: https://issues.apache.org/jira/browse/MYFACES-4605 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.1, 2.3.10 >Reporter: Joe Crichton > Assignee: Werner Punz >Priority: Major > Fix For: 2.3.11, 3.0.3 > > Attachments: image-2023-06-20-21-22-50-593.png > > > Seems this is an old issue, which was presumably fixed for MyFaces in 2.2 as > discussed here > [https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm|https://balusc.omnifaces.org/2011/09/communication-in-jsf-20.html#AjaxRenderingOfContentWhichContainsAnotherForm),] > and [https://github.com/jakartaee/faces/issues/790] > Using openliberty with jsf-3.0 feature still has this occurring. Using the > workaround outlined by the first link fixes the issue. I believe the same is > true for the jsf-2.3 feature as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737813#comment-17737813 ] Werner Punz commented on MYFACES-4610: -- have issued a pull request which soon will be merged, will issue fixes for the 2.x branches in the upcoming days! > Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 > Reporter: Werner Punz > Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4610) Fix for issuing element key:value combination breaks Tobago
[ https://issues.apache.org/jira/browse/MYFACES-4610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17737688#comment-17737688 ] Werner Punz edited comment on MYFACES-4610 at 6/27/23 3:19 PM: --- The issue here is indeed the fix we added recently that a key value pair of the issuing element is added. The problem here is that the issuing element has the same id (the virtual element tobago-select-many-checkbox but has no value, to make matters worse the embedded real inputs have the same name as the input elements id: Fix for issuing element key:value combination breaks Tobago > --- > > Key: MYFACES-4610 > URL: https://issues.apache.org/jira/browse/MYFACES-4610 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 3.0.2, 2.3-next-M8, 4.0.2 > Reporter: Werner Punz > Assignee: Werner Punz >Priority: Major > > This is a follow up issue caused by the fix for > https://issues.apache.org/jira/browse/MYFACES-4606 > raised by the Tobago guys. > The fix broke one of their testcases! > [https://github.com/henningn/myfaces-tobago.git] > 4 checkboxes on the page, example does not work anymore because > * git checkout jsfjs_next_gen402 > * mvn clean install > * cd tobago-example/tobago-example-demo > * mvn clean -Pdev -Pjetty jetty:run > * open > [http://localhost:8080/content/030-select/50-selectManyCheckbox/Multi_Checkbox.xhtml] > The request adds the issuing element with a null value! > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
