Result of: [VOTE] Release Tobago 5.7.2
Hi, thank you for checking and voting for the releases. The result is +1 Bernd Bohmann Werner Punz Udo Schnurpfeil so I will proceed with the next steps for the releases. Regards, Henning Am 19.06.23 um 20:08 schrieb Udo Schnurpfeil: +1 regards Udo Am 19.06.23 um 15:31 schrieb Werner Punz: +1 Am Mo., 19. Juni 2023 um 14:53 Uhr schrieb Bernd Bohmann : Here is my +1 Regards Bernd Henning Nöth schrieb am Mo., 19. Juni 2023, 12:33: Hello, I would like to release: * Tobago 5.7.2 The artifacts were deployed on nexus repository for binary and source packages: * Tobago 5.7.2 [1] The release notes are in Jira: * Tobago 5.7.2 [2] The artifacts are available at the staging repository (Nexus) at: * Tobago 5.7.2 [3] (sha-256 fdd81aab58ac6b822d5d9429c1ff7b6b698c967ba29bad3101875efbab8c45b7) Please vote now! (The vote is open for 72h.) [ ] +1 [ ] +0 [ ] -1 Regards, Henning [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1233 [2] https://issues.apache.org/jira/projects/TOBAGO/versions/12353344 [3] https://repository.apache.org/content/repositories/orgapachemyfaces-1233/org/apache/myfaces/tobago/tobago/5.7.2/tobago-5.7.2-source-release.zip
[GitHub] [myfaces-tobago] henningn opened a new pull request, #4134: chore: update Release.java
henningn opened a new pull request, #4134: URL: https://github.com/apache/myfaces-tobago/pull/4134 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4134: chore: update Release.java
henningn merged PR #4134: URL: https://github.com/apache/myfaces-tobago/pull/4134 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn opened a new pull request, #4135: chore: update Release.java
henningn opened a new pull request, #4135: URL: https://github.com/apache/myfaces-tobago/pull/4135 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4135: chore: update Release.java
henningn merged PR #4135: URL: https://github.com/apache/myfaces-tobago/pull/4135 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-homepage] henningn opened a new pull request, #60: docs: TLD for Tobago release 5.7.1, 5.7.2
henningn opened a new pull request, #60: URL: https://github.com/apache/myfaces-homepage/pull/60 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-homepage] henningn merged pull request #60: docs: TLD for Tobago release 5.7.1, 5.7.2
henningn merged PR #60: URL: https://github.com/apache/myfaces-homepage/pull/60 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MYFACES-4608) FACELETS_REFRESH_PERIOD Settings
[
https://issues.apache.org/jira/browse/MYFACES-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736106#comment-17736106
]
Thomas Andraschko commented on MYFACES-4608:
Would anyone like to create a spec issue plz?
> FACELETS_REFRESH_PERIOD Settings
>
>
> Key: MYFACES-4608
> URL: https://issues.apache.org/jira/browse/MYFACES-4608
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Melloware
>Priority: Major
>
> Original issue came up in Quarkus conversation:
> [https://github.com/quarkiverse/quarkus-primefaces/issues/75]
> User had this setting in web.xml and was wondering why he could not hot
> reload pages in DEV Mode
> {code:java}
>
> jakarta.faces.FACELETS_REFRESH_PERIOD
> -1
>
> {code}
> Question for the team based on what Mojarra is doing.
> # In PRODUCTION mode should we force it to -1 and ignore the user setting
> like Mojarra does?
> # If the value is not a positive number in DEV mode should we ignore it or
> log a warning?
>
> Any other ideas?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4608) FACELETS_REFRESH_PERIOD Settings
[
https://issues.apache.org/jira/browse/MYFACES-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736107#comment-17736107
]
Thomas Andraschko commented on MYFACES-4608:
[~melloware] im sure we dont support EL in the context-param. would you like to
check it and implement if you like? at least in 4.x
> FACELETS_REFRESH_PERIOD Settings
>
>
> Key: MYFACES-4608
> URL: https://issues.apache.org/jira/browse/MYFACES-4608
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Melloware
>Priority: Major
>
> Original issue came up in Quarkus conversation:
> [https://github.com/quarkiverse/quarkus-primefaces/issues/75]
> User had this setting in web.xml and was wondering why he could not hot
> reload pages in DEV Mode
> {code:java}
>
> jakarta.faces.FACELETS_REFRESH_PERIOD
> -1
>
> {code}
> Question for the team based on what Mojarra is doing.
> # In PRODUCTION mode should we force it to -1 and ignore the user setting
> like Mojarra does?
> # If the value is not a positive number in DEV mode should we ignore it or
> log a warning?
>
> Any other ideas?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [myfaces-tobago] henningn merged pull request #4132: build(deps): bump xml-maven-plugin from 1.0.2 to 1.1.0
henningn merged PR #4132: URL: https://github.com/apache/myfaces-tobago/pull/4132 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4130: build(deps): bump xml-maven-plugin from 1.0.2 to 1.1.0
henningn merged PR #4130: URL: https://github.com/apache/myfaces-tobago/pull/4130 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4133: build(deps): bump xml-maven-plugin from 1.0.2 to 1.1.0
henningn merged PR #4133: URL: https://github.com/apache/myfaces-tobago/pull/4133 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4131: build(deps): bump xml-maven-plugin from 1.0.2 to 1.1.0
henningn merged PR #4131: URL: https://github.com/apache/myfaces-tobago/pull/4131 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MYFACES-4608) FACELETS_REFRESH_PERIOD Settings
[
https://issues.apache.org/jira/browse/MYFACES-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736139#comment-17736139
]
Volodymyr Siedlecki commented on MYFACES-4608:
--
I can in a bit :)
> FACELETS_REFRESH_PERIOD Settings
>
>
> Key: MYFACES-4608
> URL: https://issues.apache.org/jira/browse/MYFACES-4608
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Melloware
>Priority: Major
>
> Original issue came up in Quarkus conversation:
> [https://github.com/quarkiverse/quarkus-primefaces/issues/75]
> User had this setting in web.xml and was wondering why he could not hot
> reload pages in DEV Mode
> {code:java}
>
> jakarta.faces.FACELETS_REFRESH_PERIOD
> -1
>
> {code}
> Question for the team based on what Mojarra is doing.
> # In PRODUCTION mode should we force it to -1 and ignore the user setting
> like Mojarra does?
> # If the value is not a positive number in DEV mode should we ignore it or
> log a warning?
>
> Any other ideas?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (MYFACES-4608) FACELETS_REFRESH_PERIOD Settings
[
https://issues.apache.org/jira/browse/MYFACES-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736139#comment-17736139
]
Volodymyr Siedlecki edited comment on MYFACES-4608 at 6/22/23 1:53 PM:
---
I can create the spec issue in a bit :)
was (Author: volosied):
I can in a bit :)
> FACELETS_REFRESH_PERIOD Settings
>
>
> Key: MYFACES-4608
> URL: https://issues.apache.org/jira/browse/MYFACES-4608
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Melloware
>Priority: Major
>
> Original issue came up in Quarkus conversation:
> [https://github.com/quarkiverse/quarkus-primefaces/issues/75]
> User had this setting in web.xml and was wondering why he could not hot
> reload pages in DEV Mode
> {code:java}
>
> jakarta.faces.FACELETS_REFRESH_PERIOD
> -1
>
> {code}
> Question for the team based on what Mojarra is doing.
> # In PRODUCTION mode should we force it to -1 and ignore the user setting
> like Mojarra does?
> # If the value is not a positive number in DEV mode should we ignore it or
> log a warning?
>
> Any other ideas?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4608) FACELETS_REFRESH_PERIOD Settings
[
https://issues.apache.org/jira/browse/MYFACES-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736156#comment-17736156
]
Melloware commented on MYFACES-4608:
[~tandraschko] can you elaborate what you mean about EL support in the Context
Param? I am a little unclear but am happy to submit a PR once I get some
guidance!
> FACELETS_REFRESH_PERIOD Settings
>
>
> Key: MYFACES-4608
> URL: https://issues.apache.org/jira/browse/MYFACES-4608
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Melloware
>Priority: Major
>
> Original issue came up in Quarkus conversation:
> [https://github.com/quarkiverse/quarkus-primefaces/issues/75]
> User had this setting in web.xml and was wondering why he could not hot
> reload pages in DEV Mode
> {code:java}
>
> jakarta.faces.FACELETS_REFRESH_PERIOD
> -1
>
> {code}
> Question for the team based on what Mojarra is doing.
> # In PRODUCTION mode should we force it to -1 and ignore the user setting
> like Mojarra does?
> # If the value is not a positive number in DEV mode should we ignore it or
> log a warning?
>
> Any other ideas?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (MYFACES-4608) FACELETS_REFRESH_PERIOD Settings
[
https://issues.apache.org/jira/browse/MYFACES-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736163#comment-17736163
]
Thomas Andraschko commented on MYFACES-4608:
[~melloware] you suggested this in the original issue:
{code:java}
jakarta.faces.FACELETS_REFRESH_PERIOD
#{facesContext.application.projectStage eq
'Development' ? 2 : -1}
{code}
i dont think this is working, servlet doesnt parse the EL, this needs to by
done in MF
> FACELETS_REFRESH_PERIOD Settings
>
>
> Key: MYFACES-4608
> URL: https://issues.apache.org/jira/browse/MYFACES-4608
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Melloware
>Priority: Major
>
> Original issue came up in Quarkus conversation:
> [https://github.com/quarkiverse/quarkus-primefaces/issues/75]
> User had this setting in web.xml and was wondering why he could not hot
> reload pages in DEV Mode
> {code:java}
>
> jakarta.faces.FACELETS_REFRESH_PERIOD
> -1
>
> {code}
> Question for the team based on what Mojarra is doing.
> # In PRODUCTION mode should we force it to -1 and ignore the user setting
> like Mojarra does?
> # If the value is not a positive number in DEV mode should we ignore it or
> log a warning?
>
> Any other ideas?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [myfaces-homepage] henningn opened a new pull request, #61: docs: download links for Tobago 5.7.1 and 5.7.2
henningn opened a new pull request, #61: URL: https://github.com/apache/myfaces-homepage/pull/61 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-homepage] henningn merged pull request #61: docs: download links for Tobago 5.7.1 and 5.7.2
henningn merged PR #61: URL: https://github.com/apache/myfaces-homepage/pull/61 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn opened a new pull request, #4136: docs: update release checklist
henningn opened a new pull request, #4136: URL: https://github.com/apache/myfaces-tobago/pull/4136 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn opened a new pull request, #4137: docs: update release checklist
henningn opened a new pull request, #4137: URL: https://github.com/apache/myfaces-tobago/pull/4137 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4136: docs: update release checklist
henningn merged PR #4136: URL: https://github.com/apache/myfaces-tobago/pull/4136 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [myfaces-tobago] henningn merged pull request #4137: docs: update release checklist
henningn merged PR #4137: URL: https://github.com/apache/myfaces-tobago/pull/4137 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@myfaces.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MYFACES-4608) FACELETS_REFRESH_PERIOD Settings
[
https://issues.apache.org/jira/browse/MYFACES-4608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17736261#comment-17736261
]
Melloware commented on MYFACES-4608:
Understood!
> FACELETS_REFRESH_PERIOD Settings
>
>
> Key: MYFACES-4608
> URL: https://issues.apache.org/jira/browse/MYFACES-4608
> Project: MyFaces Core
> Issue Type: New Feature
> Components: General
>Affects Versions: 2.3.10, 3.0.2, 2.3-next-M8, 4.0.1
>Reporter: Melloware
>Priority: Major
>
> Original issue came up in Quarkus conversation:
> [https://github.com/quarkiverse/quarkus-primefaces/issues/75]
> User had this setting in web.xml and was wondering why he could not hot
> reload pages in DEV Mode
> {code:java}
>
> jakarta.faces.FACELETS_REFRESH_PERIOD
> -1
>
> {code}
> Question for the team based on what Mojarra is doing.
> # In PRODUCTION mode should we force it to -1 and ignore the user setting
> like Mojarra does?
> # If the value is not a positive number in DEV mode should we ignore it or
> log a warning?
>
> Any other ideas?
--
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&focusedCommentId=17736367#comment-17736367 ] Werner Punz commented on MYFACES-4605: -- Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! Does not change the fact that the id can change from one response to the other hence you always should rely on the viewstate in the id or viewstate as name which is always permanent for viewstate element detection never on a permanent id. (but that also can happen during server side rendering theoretically) I will change that at the weekend accordingly. The rest I see as no bug and works as expected, if you all can agree as well (gave the explanation already) > 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] [Comment Edited] (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&focusedCommentId=17736367#comment-17736367 ] Werner Punz edited comment on MYFACES-4605 at 6/23/23 6:49 AM: --- Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! Does not change the fact that the id can change from one response to the other hence you always should rely on the viewstate in the id or viewstate as name which is always permanent for viewstate element detection never on a permanent id. (but that also can happen during server side rendering theoretically) I will change that at the weekend accordingly. The rest I see as no bug and works as expected, if you all can agree as well (gave the explanation already) PS: Another possible solution would be to include the viewstate nevertheless in the form response that way the viewstate in the viestate update tag would only update the embedded viewstate. But that would need a small server side fix someone else has to perform. From the js code it makes no difference a) No Viewstate element, the element is added at the last processing step b) Viewstate element present in the form, only the value is updated with the one coming in from the tag, then also the id would not change compared to the embedded one. If you want to implement this option then we have 2 viewstate definitions in the response but also the advantage of server side id control! Either option is fine the 0->1 fix must be added anyway, the other option wont break the js code! was (Author: werpu): Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! Does not change the fact that the id can change from one response to the other hence you always should rely on the viewstate in the id or viewstate as name which is always permanent for viewstate element detection never on a permanent id. (but that also can happen during server side rendering theoretically) I will change that at the weekend accordingly. The rest I see as no bug and works as expected, if you all can agree as well (gave the explanation already) > 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] [Comment Edited] (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&focusedCommentId=17736367#comment-17736367 ] Werner Punz edited comment on MYFACES-4605 at 6/23/23 6:51 AM: --- Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! Does not change the fact that the id can change from one response to the other hence you always should rely on the viewstate in the id or viewstate as name which is always permanent for viewstate element detection never on a permanent id. (but that also can happen during server side rendering theoretically) I will change that at the weekend accordingly. The rest I see as no bug and works as expected, if you all can agree as well (gave the explanation already) PS: Another possible solution would be to include the viewstate nevertheless in the form response that way the viewstate in the viestate update tag would only update the embedded viewstate. But that would need a small server side fix someone else has to perform. From the js code it makes no difference a) No Viewstate element, the element is added at the last processing step b) Viewstate element present in the form, only the value is updated with the one coming in from the tag, then also the id would not change compared to the embedded one. If you want to implement this option then we have 2 viewstate definitions in the response but also the advantage of server side id control! Either option is fine the 0->1 fix must be added anyway, the other option wont break the js code! I am not entirely sure how Mojarra behaves for this case, I guess we should be in sync with their response pattern here! was (Author: werpu): Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! Does not change the fact that the id can change from one response to the other hence you always should rely on the viewstate in the id or viewstate as name which is always permanent for viewstate element detection never on a permanent id. (but that also can happen during server side rendering theoretically) I will change that at the weekend accordingly. The rest I see as no bug and works as expected, if you all can agree as well (gave the explanation already) PS: Another possible solution would be to include the viewstate nevertheless in the form response that way the viewstate in the viestate update tag would only update the embedded viewstate. But that would need a small server side fix someone else has to perform. From the js code it makes no difference a) No Viewstate element, the element is added at the last processing step b) Viewstate element present in the form, only the value is updated with the one coming in from the tag, then also the id would not change compared to the embedded one. If you want to implement this option then we have 2 viewstate definitions in the response but also the advantage of server side id control! Either option is fine the 0->1 fix must be added anyway, the other option wont break the js code! > 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] [Comment Edited] (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&focusedCommentId=17736367#comment-17736367 ] Werner Punz edited comment on MYFACES-4605 at 6/23/23 6:53 AM: --- Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! PS: Another possible solution would be to include the viewstate nevertheless in the form response that way the Viewstate in the update tag would only update the embedded ViewState. But that would need a small server side fix someone else has to perform. From the js code perspective, it makes no difference a) No Viewstate element, the element is added at the last processing step b) Viewstate element present in the form, only the value is updated with the one coming in from the tag, then also the id would not change compared to the embedded one. These are the two cases which must be supported as per spec, afair. I am not entirely sure how Mojarra behaves for this case, I guess we should be in sync with their response xml patterns here! was (Author: werpu): Yes the id is beginning with 0. That is a "bug" in a sense that I was not aware that the id starts with one if the viewstate is server rendered we can change that easily, that must be done on all branches. I can do that at the weekend! Does not change the fact that the id can change from one response to the other hence you always should rely on the viewstate in the id or viewstate as name which is always permanent for viewstate element detection never on a permanent id. (but that also can happen during server side rendering theoretically) I will change that at the weekend accordingly. The rest I see as no bug and works as expected, if you all can agree as well (gave the explanation already) PS: Another possible solution would be to include the viewstate nevertheless in the form response that way the viewstate in the viestate update tag would only update the embedded viewstate. But that would need a small server side fix someone else has to perform. From the js code it makes no difference a) No Viewstate element, the element is added at the last processing step b) Viewstate element present in the form, only the value is updated with the one coming in from the tag, then also the id would not change compared to the embedded one. If you want to implement this option then we have 2 viewstate definitions in the response but also the advantage of server side id control! Either option is fine the 0->1 fix must be added anyway, the other option wont break the js code! I am not entirely sure how Mojarra behaves for this case, I guess we should be in sync with their response pattern here! > 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)
