[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16275740#comment-16275740 ] Werner Punz edited comment on MYFACES-4160 at 12/2/17 8:31 PM: --- Fixed and committed. Eduardo brejos usecase. I will now investigate the usecase from Thomas was (Author: werpu): Fixed and committed. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > Attachments: test1.xhtml > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1619#comment-1619 ] Werner Punz edited comment on MYFACES-4160 at 10/9/17 8:39 AM: --- The example from MYFACES-4156 looks fine now. My testing has shown that both forms get a new viewstate upon submission. Also the entire ajax response is now way simpler because I do not have to deal with the pesky render target elements anymore. was (Author: werpu): The example from MYFACES-4156 looks fine now. My testing has shown that both forms get a new viewstate upon submission. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196313#comment-16196313 ] Werner Punz edited comment on MYFACES-4160 at 10/8/17 7:57 PM: --- Ok got in contact with one of the EG guys and it seems the spec again is wrong here. I have sent some info forward to the Mojarra devs and will for now go forward with my propose solution which seems to be correct, lets wait for the reaction on Mojarras side on this matter. Btw. the new issue tracker is: https://github.com/javaee/javaserverfaces-spec/issues/ respectively the underlying issue is: https://github.com/javaee/javaserverfaces-spec/issues/790 was (Author: werpu): Ok got in contact with one of the EG guys and it seems the spec again is wrong here. I have sent some info forward to the Mojarra devs and will fopr now go forward with my propose solution which seems to be correct, lets wait for the reaction on Mojarras side on this matter. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196287#comment-16196287 ] Werner Punz edited comment on MYFACES-4160 at 10/8/17 7:03 PM: --- Ok again the spec seems at fault here - I guess this is a topic hard to get right. I will implement the in my opinion correct solution for now and will get in contact with some of the EG guys. But please also check this weird namespaced ajax response from us, it does not seem to be correct. was (Author: werpu): Ok again the spec seems at fault here - I guess this is a topic hard to get right. I will implement the in my opinion correct solution for now and will get in contact with some of the EG guys. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196287#comment-16196287 ] Werner Punz edited comment on MYFACES-4160 at 10/8/17 7:02 PM: --- Ok again the spec seems at fault here - I guess this is a topic hard to get right. I will implement the in my opinion correct solution for now and will get in contact with some of the EG guys. was (Author: werpu): Ok again the spec seems at fault here, partially my fault, I should have followed the 790 thread more thoroughly instead of just checking the proposed solutions from time to time. I will implement the in my opinion correct solution for now and will get in contact with some of the EG guys. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196266#comment-16196266 ] Werner Punz edited comment on MYFACES-4160 at 10/8/17 6:26 PM: --- Ok I rechecked the docs, and I think the spec was not properly updated. I know there was a long thread discussing the solution and I personally think the correct solution was to update the issuing form and all forms ander a view root. Which also is basically what is stated on Tijms Weblog. However the jsdocs state: *f the javax.faces.ViewState element could not be found, throw an error. If the ID of the javax.faces.ViewState element has a prefix, where is the currently configured UINamingContainer.getSeparatorChar() and is the return from UIViewRoot.getContainerClientId() on the view from whence this state originated, then remember it as namespace prefix. This is needed during encoding of the set of post data arguments.* Which implemented word by word simply causes some viewstates under a naming container to be not updated again. Again I state, all forms under one given viewroot must be updated, otherwise you will simply get old stale broken viewstates. If the stated viewroot element cannot be found then we do not have multiple viewroots, so the update root then is the body in a html environment. As it is Is stated in the jsdocs, which was carried over from the old spec with the broken issue, render target pattern. The problem I have is, the old java.net issue thread https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790 is gone because oracle has pulled it due to the shutdown of java.net. My personal guess is Mojarra implemented the correct pattern as it was discussed, But the specs or at least the jsdocs were updated sloppily othwise it would have crawled up again. Does anyone know where the JSF issues have been moved? I need to dig up the thread. In the meanwhile I will implement the solution which is correct in my opinion we will see if the TCK will fail or not. I will give the google history a shot maybe I can still dig the vital info out. was (Author: werpu): Ok I rechecked the docs, and I think the spec was not properly updated. I know there was a long thread discussing the solution and I personally think the correct solution was to update the issuing form and all forms ander a view root. Which also is basically what is stated on Tijms Weblog. *f the javax.faces.ViewState element could not be found, throw an error. If the ID of the javax.faces.ViewState element has a prefix, where is the currently configured UINamingContainer.getSeparatorChar() and is the return from UIViewRoot.getContainerClientId() on the view from whence this state originated, then remember it as namespace prefix. This is needed during encoding of the set of post data arguments.* Which implemented word by word simply causes some viewstates under a naming container to be not updated again. Again I state, all forms under one given viewroot must be updated, otherwise you will simply get old stale broken viewstates. If the stated viewroot element cannot be found then we do not have multiple viewroots, so the update root then is the body in a html environment. As it is Is stated in the jsdocs, which was carried over from the old spec with the broken issue, render target pattern. The problem I have is, the old java.net issue thread https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790 is gone because oracle has pulled it due to the shutdown of java.net. My personal guess is Mojarra implemented the correct pattern as it was discussed, But the specs or at least the jsdocs were updated sloppily othwise it would have crawled up again. Does anyone know where the JSF issues have been moved? I need to dig up the thread. In the meanwhile I will implement the solution which is correct in my opinion we will see if the TCK will fail or not. I will give the google history a shot maybe I can still dig the vital info out. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196266#comment-16196266 ] Werner Punz edited comment on MYFACES-4160 at 10/8/17 6:26 PM: --- Ok I rechecked the docs, and I think the spec was not properly updated. I know there was a long thread discussing the solution and I personally think the correct solution was to update the issuing form and all forms ander a view root. Which also is basically what is stated on Tijms Weblog. *f the javax.faces.ViewState element could not be found, throw an error. If the ID of the javax.faces.ViewState element has a prefix, where is the currently configured UINamingContainer.getSeparatorChar() and is the return from UIViewRoot.getContainerClientId() on the view from whence this state originated, then remember it as namespace prefix. This is needed during encoding of the set of post data arguments.* Which implemented word by word simply causes some viewstates under a naming container to be not updated again. Again I state, all forms under one given viewroot must be updated, otherwise you will simply get old stale broken viewstates. If the stated viewroot element cannot be found then we do not have multiple viewroots, so the update root then is the body in a html environment. As it is Is stated in the jsdocs, which was carried over from the old spec with the broken issue, render target pattern. The problem I have is, the old java.net issue thread https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790 is gone because oracle has pulled it due to the shutdown of java.net. My personal guess is Mojarra implemented the correct pattern as it was discussed, But the specs or at least the jsdocs were updated sloppily othwise it would have crawled up again. Does anyone know where the JSF issues have been moved? I need to dig up the thread. In the meanwhile I will implement the solution which is correct in my opinion we will see if the TCK will fail or not. I will give the google history a shot maybe I can still dig the vital info out. was (Author: werpu): Ok I rechecked the docs, and I think the spec was not properly updated. I know there was a long thread discussing the solution and I personally think the correct solution was to update the issuing form and all forms ander a view root. *f the javax.faces.ViewState element could not be found, throw an error. If the ID of the javax.faces.ViewState element has a prefix, where is the currently configured UINamingContainer.getSeparatorChar() and is the return from UIViewRoot.getContainerClientId() on the view from whence this state originated, then remember it as namespace prefix. This is needed during encoding of the set of post data arguments.* Which implemented word by word simply causes some viewstates under a naming container to be not updated again. Again I state, all forms under one given viewroot must be updated, otherwise you will simply get old stale broken viewstates. If the stated viewroot element cannot be found then we do not have multiple viewroots, so the update root then is the body in a html environment. As it is Is stated in the jsdocs, which was carried over from the old spec with the broken issue, render target pattern. The problem I have is, the old java.net issue thread https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790 is gone because oracle has pulled it due to the shutdown of java.net. My personal guess is Mojarra implemented the correct pattern as it was discussed, But the specs or at least the jsdocs were updated sloppily othwise it would have crawled up again. Does anyone know where the JSF issues have been moved? I need to dig up the thread. In the meanwhile I will implement the solution which is correct in my opinion we will see if the TCK will fail or not. I will give the google history a shot maybe I can still dig the vital info out. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196266#comment-16196266 ] Werner Punz edited comment on MYFACES-4160 at 10/8/17 6:11 PM: --- Ok I rechecked the docs, and I think the spec was not properly updated. I know there was a long thread discussing the solution and I personally think the correct solution was to update the issuing form and all forms ander a view root. *f the javax.faces.ViewState element could not be found, throw an error. If the ID of the javax.faces.ViewState element has a prefix, where is the currently configured UINamingContainer.getSeparatorChar() and is the return from UIViewRoot.getContainerClientId() on the view from whence this state originated, then remember it as namespace prefix. This is needed during encoding of the set of post data arguments.* Which implemented word by word simply causes some viewstates under a naming container to be not updated again. Again I state, all forms under one given viewroot must be updated, otherwise you will simply get old stale broken viewstates. If the stated viewroot element cannot be found then we do not have multiple viewroots, so the update root then is the body in a html environment. As it is Is stated in the jsdocs, which was carried over from the old spec with the broken issue, render target pattern. The problem I have is, the old java.net issue thread https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790 is gone because oracle has pulled it due to the shutdown of java.net. My personal guess is Mojarra implemented the correct pattern as it was discussed, But the specs or at least the jsdocs were updated sloppily othwise it would have crawled up again. Does anyone know where the JSF issues have been moved? I need to dig up the thread. In the meanwhile I will implement the solution which is correct in my opinion we will see if the TCK will fail or not. I will give the google history a shot maybe I can still dig the vital info out. was (Author: werpu): Ok I rechecked the docs, and I think the spec was not properly updated. I know there was a long thread discussing the solution and I personally think the correct solution was to update the issuing form and all forms ander a view root. *f the javax.faces.ViewState element could not be found, throw an error. If the ID of the javax.faces.ViewState element has a prefix, where is the currently configured UINamingContainer.getSeparatorChar() and is the return from UIViewRoot.getContainerClientId() on the view from whence this state originated, then remember it as namespace prefix. This is needed during encoding of the set of post data arguments.* Which implemented word by word simply causes some viewstates under a naming container to be not updated again. Again I state, all forms under one given viewroot must be updated, otherwise you will simply get old stale broken viewstates. If the stated viewroot element cannot be found then we do not have multiple viewroots, so the update root then is the body in a html environment. As it is Is stated in the jsdocs, which was carried over from the old spec with the broken issuer, render target pattern. The problem I have is, the old java.net issue thread https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790 is gone because oracle has pulled it due to the shutdown of java.net. Does anyone know where the JSF issues have been moved? I need to dig up the thread. In the meanwhile I will implement the solution which is correct in my opinion we will see if the TCK will fail or not. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196210#comment-16196210 ] Thomas Andraschko edited comment on MYFACES-4160 at 10/8/17 4:38 PM: - Hmm, how did it work in 2.2? I'm also not sure if we talk about the same "namespacing". I talk about this one: https://issues.apache.org/jira/browse/MYFACES-4053 I thought that viewroot namespacing should also only happen in portlet environments. was (Author: tandraschko): Hmm, how did it work in 2.2? I'm also not sure if we talk about the same "namespacing". I talk about this one: https://issues.apache.org/jira/browse/MYFACES-4053 > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196209#comment-16196209 ] Werner Punz edited comment on MYFACES-4160 at 10/8/17 4:36 PM: --- Ah yes the second problem, intiially both viewstate elements were prefixed perfectly fine, but upon replacement the cdata block does not have a viewstate in, which also is fine, but then the in conjunction with a partial response with an id comes along and the viewstate element cannot be added to the first form anymore since the form id is not prefixed with j_id__v_0 So I guess there are some bugs regarding the viewroot name handling. Either leave out the j_id__v_0 for the partial response block so that all forms are picked up or put the prefix into all elements under this viewroot. was (Author: werpu): Ah yes the second problem, intiially both viewstate elements were prefixed perfectly fine, but upon replacement the cdata block does not have a viewstate in, which also is fine, but then the comes along and the viewstate element cannot be added to the first form anymore since the form id is not prefixed with j_id__v_0 So I guess there are some bugs regarding the viewroot name handling. Either leave out the j_id__v_0 for the partial response block so that all forms are picked up or put the prefix into all elements under this viewroot. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196164#comment-16196164 ] Werner Punz edited comment on MYFACES-4160 at 10/8/17 3:24 PM: --- I am done with the needed changes, and I would be ready to commit however. before committing it I would like to check the the code in the JSF - CDI example app. However I cannot get it up and running, there are several issues. a) The code references websockets, but the pom.xml does not have a websocket reference - thats easy to fix. b) Whenever I dump the war into Tomcat I get a CDI error: nfig.annotation.Tomcat7AnnotationLifecycleProvider 08-Oct-2017 17:09:45.158 SCHWERWIEGEND [main] org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces An error occured while initializing MyFaces: It's not allowed to call getBeans(Type, Annotation...) before AfterBeanDiscovery java.lang.IllegalStateException: It's not allowed to call getBeans(Type, Annotation...) before AfterBeanDiscovery at org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:402) at org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:121) at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:51) at org.apache.myfaces.flow.cdi.DefaultCDIFacesFlowProvider.getAnnotatedFlows(DefaultCDIFacesFlowProvider.java:52) at org.apache.myfaces.flow.impl.AnnotatedFlowConfigurator.configureAnnotatedFlows(AnnotatedFlowConfigurator.java:42) at org.apache.myfaces.config.FacesConfigurator.configureFlowHandler(FacesConfigurator.java:1700) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:614) at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:452) at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:74) This must be fixed on the codeside. Shall I open a Jira issue for that one? So there is no real way to test this stuff atm. I ran my usual integration tests (which I host on github sort of as a workspace for myself) which I use for development. but a final test on my side is still pending. Shall I push the code anyway and someone with a working running config wants to test it? The changes do not break anything, my about 20-30 or so integration tests I have on the code pass perfectly, but I would love to see the new behavior to be tested (aka the namespaced changes). was (Author: werpu): I would be ready to commit however. before committing it I would like to check the the code in the JSF - CDI example app. However I cannot get it up and running, there are several issues. a) The code references websockets, but the pom.xml does not have a websocket reference - thats easy to fix. b) Whenever I dump the war into Tomcat I get a CDI error: nfig.annotation.Tomcat7AnnotationLifecycleProvider 08-Oct-2017 17:09:45.158 SCHWERWIEGEND [main] org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces An error occured while initializing MyFaces: It's not allowed to call getBeans(Type, Annotation...) before AfterBeanDiscovery java.lang.IllegalStateException: It's not allowed to call getBeans(Type, Annotation...) before AfterBeanDiscovery at org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:402) at org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:121) at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:51) at org.apache.myfaces.flow.cdi.DefaultCDIFacesFlowProvider.getAnnotatedFlows(DefaultCDIFacesFlowProvider.java:52) at org.apache.myfaces.flow.impl.AnnotatedFlowConfigurator.configureAnnotatedFlows(AnnotatedFlowConfigurator.java:42) at org.apache.myfaces.config.FacesConfigurator.configureFlowHandler(FacesConfigurator.java:1700) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:614) at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:452) at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:74) This must be fixed on the codeside. Shall I open a Jira issue for that one? So there is no real way to test this stuff atm. I ran my usual integration tests (which I host on github sort of as a workspace for myself) which I use for development. but a final test on my side is still pending. Shall I push the code anyway and someone with a working running config wants to test it? The changes do not break anything, my about 20-30 or so integration tests I have on the code pass perfectly, but I would love to see the new behavior to be tested (aka the
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196164#comment-16196164 ] Werner Punz edited comment on MYFACES-4160 at 10/8/17 3:21 PM: --- I would be ready to commit however. before committing it I would like to check the the code in the JSF - CDI example app. However I cannot get it up and running, there are several issues. a) The code references websockets, but the pom.xml does not have a websocket reference - thats easy to fix. b) Whenever I dump the war into Tomcat I get a CDI error: nfig.annotation.Tomcat7AnnotationLifecycleProvider 08-Oct-2017 17:09:45.158 SCHWERWIEGEND [main] org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces An error occured while initializing MyFaces: It's not allowed to call getBeans(Type, Annotation...) before AfterBeanDiscovery java.lang.IllegalStateException: It's not allowed to call getBeans(Type, Annotation...) before AfterBeanDiscovery at org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:402) at org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:121) at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:51) at org.apache.myfaces.flow.cdi.DefaultCDIFacesFlowProvider.getAnnotatedFlows(DefaultCDIFacesFlowProvider.java:52) at org.apache.myfaces.flow.impl.AnnotatedFlowConfigurator.configureAnnotatedFlows(AnnotatedFlowConfigurator.java:42) at org.apache.myfaces.config.FacesConfigurator.configureFlowHandler(FacesConfigurator.java:1700) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:614) at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:452) at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:74) This must be fixed on the codeside. Shall I open a Jira issue for that one? So there is no real way to test this stuff atm. I ran my usual integration tests (which I host on github sort of as a workspace for myself) which I use for development. but a final test on my side is still pending. Shall I push the code anyway and someone with a working running config wants to test it? The changes do not break anything, my about 20-30 or so integration tests I have on the code pass perfectly, but I would love to see the new behavior to be tested (aka the namespaced changes). was (Author: werpu): I would be ready to commit however. before committing it I would like to check the the code in the JSF - CDI example app. However I cannot get it up and running, there are several issues. a) The code references websockets, but the pom.xml does not have a websocket reference - thats easy to fix. b) Whenever I dump the war into Tomcat I get a CDI error: nfig.annotation.Tomcat7AnnotationLifecycleProvider 08-Oct-2017 17:09:45.158 SCHWERWIEGEND [main] org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces An error occured while initializing MyFaces: It's not allowed to call getBeans(Type, Annotation...) before AfterBeanDiscovery java.lang.IllegalStateException: It's not allowed to call getBeans(Type, Annotation...) before AfterBeanDiscovery at org.apache.webbeans.container.InjectableBeanManager.checkAfterBeanDiscoveryProcessed(InjectableBeanManager.java:402) at org.apache.webbeans.container.InjectableBeanManager.getBeans(InjectableBeanManager.java:121) at org.apache.myfaces.cdi.util.CDIUtils.lookup(CDIUtils.java:51) at org.apache.myfaces.flow.cdi.DefaultCDIFacesFlowProvider.getAnnotatedFlows(DefaultCDIFacesFlowProvider.java:52) at org.apache.myfaces.flow.impl.AnnotatedFlowConfigurator.configureAnnotatedFlows(AnnotatedFlowConfigurator.java:42) at org.apache.myfaces.config.FacesConfigurator.configureFlowHandler(FacesConfigurator.java:1700) at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:614) at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:452) at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:74) This must be fixed on the codeside. Shall I open a Jira issue for that one? So there is no real way to test this stuff atm. I ran my usual integration tests (which I host on github sort of as a workspace for myself) which I use for development. but a final test on my side is still pending. Shall I push the code anyway and someone with a working running config wants to test it? The changes do not break anything, my about 15 or so tests I have on the code pass perfectly, but I would love to see the new behavior to be tested (aka the namespaced changes). > ViewState not written for Ajax
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192522#comment-16192522 ] Werner Punz edited comment on MYFACES-4160 at 10/5/17 6:39 AM: --- Just wanted to give a status update, I have implemented basically the new response behavior but I need to write some tests first before dropping the code into the myfaces codebase. The entire viewstate handling has become tighter, it is just basically determine the viewroot if an updates id is given and then update all forms under this viewRoot as usual with the given artifact (clientWindowId, Viewstate etc...) So all this special handling regarding issuing element, rendered fragment, our special handling for non portlet multiform environments all gone. This is good news because I was really unhappy with this part due to the fixes and workarounds it had, caused by the broken jsf 2.0-2.2 spec in this area. (God knows I reported the spec bug for JSF 2.0) Expect the code if all goes well (I need to recheck the spec if I have covered all, for now I was using the Tijms weblog to get a quick grasp) late weekend, monday. Once this is implemented I will start the discussion on the mailing list on how we proceed with the reimplementation, for now I have two options use Typescript, a language which I am very familiar with due to my daywork, also we could use the Kotlin -> Javascript crosscompiler which I need to evaluate if the compiles really need kotlin.js if we do not use their core lib. I do not want to go to pure javascript again, it has so many advantages to use a better language especially since we cannot target ES6 anyway. was (Author: werpu): Just wanted to give a status update, I have implemented basically the new response behavior but I need to write some tests first before dropping the code into the myfaces codebase. The entire viewstate handling has become tighter, it is just basically determine the viewroot if an updates id is given and then update all forms under this viewRoot as usual with the given artifact (clientWindowId, Viewstate etc...) So all this special handling regarding issuing element, rendered fragment, our special handling for non portlet multiform environments all gone. This is good news because I was really unhappy with this part due to the fixes and workarounds it had, caused by the broken jsf 2.0-2.2 spec in this area. (God knows I reported the spec bug for JSF 2.0) Expect the code if all goes well (I need to recheck the spec if I have covered all, for now I was using the Tijms weblog to get a quick grasp) late weekend, monday. Once this is implemented I will start the discussion on the mailing list on how we proceed with the reimplementation, for now I have two options use Typescript, a language which I am very familiar with due to my daywork, also we could use the Kotlin -> Javascript crosscompiler which I need to evaluate. I do not want to go to pure javascript again, it has so many advantages to use a better language especially since we cannot target ES6 anyway. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16192522#comment-16192522 ] Werner Punz edited comment on MYFACES-4160 at 10/5/17 6:38 AM: --- Just wanted to give a status update, I have implemented basically the new response behavior but I need to write some tests first before dropping the code into the myfaces codebase. The entire viewstate handling has become tighter, it is just basically determine the viewroot if an updates id is given and then update all forms under this viewRoot as usual with the given artifact (clientWindowId, Viewstate etc...) So all this special handling regarding issuing element, rendered fragment, our special handling for non portlet multiform environments all gone. This is good news because I was really unhappy with this part due to the fixes and workarounds it had, caused by the broken jsf 2.0-2.2 spec in this area. (God knows I reported the spec bug for JSF 2.0) Expect the code if all goes well (I need to recheck the spec if I have covered all, for now I was using the Tijms weblog to get a quick grasp) late weekend, monday. Once this is implemented I will start the discussion on the mailing list on how we proceed with the reimplementation, for now I have two options use Typescript, a language which I am very familiar with due to my daywork, also we could use the Kotlin -> Javascript crosscompiler which I need to evaluate. I do not want to go to pure javascript again, it has so many advantages to use a better language especially since we cannot target ES6 anyway. was (Author: werpu): Just wanted to give a status update, I have implemented basically the new response behavior but I need to write some tests first before dropping the code into the myfaces codebase. The entire viewstate handling has become tighter, it is just basically determine the viewroot if an updates id is given and then update all forms under this viewRoot as usual with the given artifact (clientWindowId, Viewstate etc...) So all this special handling regarding issuing element, rendered fragment, our special handling for non portlet multiform environments all gone. This is good news because I was really unhappy with this part due to the fixes and workarounds it had, caused by the broken jsf 2.0-2.2 spec in this area. (God knows I reported the spec bug for JSF 2.0) Expect the code if all goes well (I need to recheck the spec if I have covered all, for now I was using the Tijms weblog to get a quick grasp) late weekend, monday. Once this is implemented I will start the discussion on the mailing list on how we proceed with the reimplementation, for now I have two options use Typescript, a language which I am very familiar with due to my daywork, also we could use the Kotlin -> Javascript crosscompiler which I need to evaluate. I do not want to go to pure javascript again, it has so many advantages to use a better language. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16184259#comment-16184259 ] Werner Punz edited comment on MYFACES-4160 at 9/28/17 2:37 PM: --- Just checked the primefaces code one of the reasons is, it utilizes jquery which does the heavy lifiting in the browser compatibility dom and Ajax area. That back then was out of the question for me because the sources needed to be self contained, I did not have the luxury of being able to bundle jquery. I would say about 40% of the old code is dealing with browser incompatbilities and custom browser behavior which were serious back then, have in mind when the code was developed, the main platforms were ie6 and to some degree also still blackberry on the mobile sector. But yes, the code needs a serious overhaul, I agree. It is now almost 10 years old and things have moved on big time. was (Author: werpu): Just checked the primefaces code one of the reasons is, it utilizes jquery which does the heavy lifiting in the browser compatibility dom and Ajax area. That back then was out of the question for me because the sources needed to be self contained, I did not have the luxury of being able to bundle jquery. I would say about 40% of the old code is dealing with browser incompatbilities which were serious back then, have in mind when the code was developed, the main platforms were ie6 and to some degree also still blackberry on the mobile sector. But yes, the code needs a serious overhaul, I agree. It is now almost 10 years old and things have moved on big time. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183934#comment-16183934 ] Werner Punz edited comment on MYFACES-4160 at 9/28/17 10:02 AM: Well you can remove parts of it out of the box... There is an internal switch to my knowledge which switches between xhr indirections, IE7 and older uses the old xhr mechanism, and newer browser switch to the standardized xhr object - there is no browser anymore which uses a non standardized xhr system, since IE6 is absolutely dead by now. I think I have the same switch also for the domUtils, but I need to check this first. As for the typescript maven integration i need to check the state of things out. I would prefer typescript over pure javascript due to the typing and really excellent syntax, as well as the possibility to change module systems and es levels on the fly. If possible I would not go the pure Javascript route anymore. Btw. there is an excellent client side plugin for maven which installs the entire npm toolchain during the build temporarily. This might be the way to go. After all you need the typescript compile anyway only during development, the javascripts are then checked in and do not need any further processing by maven during the normal builds. We probably can add it to a dev profile or dev-javascript profile. was (Author: werpu): Well you can remove parts of it out of the box... There is an internal switch to my knowledge which switches between xhr indirections, IE7 and older uses the old xhr mechanism, and newer browser switch to the standardized xhr object - there is no browser anymore which uses a non standardized xhr system, since IE6 is absolutely dead by now. I think I have the same switch also for the domUtils, but I need to check this first. As for the typescript maven integration i need to check the state of things out. I would prefer typescript over pure javascript due to the typing and really excellent syntax, as well as the possibility to change module systems and es levels on the fly. If possible I would not go the pure Javascript route anymore. Btw. there is an excellent client side plugin for maven which installs the entire npm toolchain during the build temporarily. This might be the way to go. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183934#comment-16183934 ] Werner Punz edited comment on MYFACES-4160 at 9/28/17 9:58 AM: --- Well you can remove parts of it out of the box... There is an internal switch to my knowledge which switches between xhr indirections, IE7 and older uses the old xhr mechanism, and newer browser switch to the standardized xhr object - there is no browser anymore which uses a non standardized xhr system, since IE6 is absolutely dead by now. I think I have the same switch also for the domUtils, but I need to check this first. As for the typescript maven integration i need to check the state of things out. I would prefer typescript over pure javascript due to the typing and really excellent syntax, as well as the possibility to change module systems and es levels on the fly. If possible I would not go the pure Javascript route anymore. Btw. there is an excellent client side plugin for maven which installs the entire npm toolchain during the build temporarily. This might be the way to go. was (Author: werpu): Well you can remove parts of it out of the box... There is an internal switch to my knowledge which switches between xhr indirections, IE7 and older uses the old xhr mechanism, and newer browser switch to the standardized xhr object - there is no browser anymore which uses a non standardized xhr system, since IE6 is absolutely dead by now. I think I have the same switch also for the domUtils, but I need to check this first. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183750#comment-16183750 ] Werner Punz edited comment on MYFACES-4160 at 9/28/17 6:41 AM: --- I am going to assign this issue to me, I will fix it in the the js codebase next weeks timeframe. was (Author: werpu): I am going to assign this issue to me, I will fix it in the next weeks timeframe. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko >Assignee: Werner Punz > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183744#comment-16183744 ] Werner Punz edited comment on MYFACES-4160 at 9/28/17 6:40 AM: --- Hi I am a little bit bound by other things this week, (one of them is to get out another ext-scripting release), I will to get back to you sometime next week. I think AjaxResponse22 is not really workable code, I need to check it - it should not have made it into the codebase, I think. But take this with a grain of salt it has been a while. In any way, the viewstate handling has been altered for jsf 2.3, we need to fix this in our code, there was no fix without breaking jsf.js code because the old viewstate handling was broken by design. In the long run we should replace the existing javascripts since it is rather old. There is a load of code in there which is obsolete: Also we need to add Websockets, which is also part of the JSF 2.3 js part. (I need to look into that) a) We use our own class system based in prototype b) We support stone old browsers, we should ramp it up to IE9 as baseline I guess, I wonder if anyone still uses any IE below that in a corporate environment? c) We might rewrite the code in Typescript for maintainability reasons, this would allow us to ramp up the Ecmascript level dynamically and also to switch module systems on the fly (aka with ES6 a standardized module system was finally introduced) I have started to work on it on a github project this summer... but I never publicly announced it since the entire thing is not in a representable state yet. What I would propose is following: a) Fix the old codebase for JSF 2.3 b) Lets reimplement the stuff in Typescript with a bunch of helpers from modern libs like a dom query engine and Promise shims and drop really old browser support along the way - so that we can offer the new codebase sometime along jsf 2.3. c) Drop the old codebase for JSF 2.4 Anyway I will pick the fix for the old js up next week. was (Author: werpu): Hi I am a little bit bound by other things this week, (one of them is to get out another ext-scripting release), I will to get back to you sometime next week. I think AjaxResponse22 is not really workable code, I need to check it - it should not have made it into the codebase, I think. But take this with a grain of salt it has been a while. In any way, the viewstate handling has been altered for jsf 2.3, we need to fix this in our code, there was no fix without breaking jsf.js code because the old viewstate handling was broken by design. In the long run we should replace the existing javascripts since it is rather old. There is a load of code in there which is obsolete: Also we need to add Websockets, which is also part of the JSF 2.3 js part. (I need to look into that) a) We use our own class system based in prototype b) We support stone old browsers, we should ramp it up to IE9 as baseline I guess, I wonder if anyone still uses any IE below that in a corporate environment? c) We might rewrite the code in Typescript for maintainability reasons, this would allow us to ramp up the Ecmascript level dynamically and also to switch module systems on the fly (aka with ES6 a standardized module system was finally introduced) I have started to work on it on a github project this summer... but I never publicly announced it since the entire thing is not in a representable state yet. What I would propose is following: a) Fix the old codebase for JSF 2.3 b) Lets reimplement the stuff in Typescript with a bunch of helpers from modern libs like a dom query engine and Promise shims and drop really old browser support along the way - so that we can offer the new codebase sometime along jsf 2.3. c) Drop the old codebase for JSF 2.4 > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183744#comment-16183744 ] Werner Punz edited comment on MYFACES-4160 at 9/28/17 6:38 AM: --- Hi I am a little bit bound by other things this week, (one of them is to get out another ext-scripting release), I will to get back to you sometime next week. I think AjaxResponse22 is not really workable code, I need to check it - it should not have made it into the codebase, I think. But take this with a grain of salt it has been a while. In any way, the viewstate handling has been altered for jsf 2.3, we need to fix this in our code, there was no fix without breaking jsf.js code because the old viewstate handling was broken by design. In the long run we should replace the existing javascripts since it is rather old. There is a load of code in there which is obsolete: Also we need to add Websockets, which is also part of the JSF 2.3 js part. (I need to look into that) a) We use our own class system based in prototype b) We support stone old browsers, we should ramp it up to IE9 as baseline I guess, I wonder if anyone still uses any IE below that in a corporate environment? c) We might rewrite the code in Typescript for maintainability reasons, this would allow us to ramp up the Ecmascript level dynamically and also to switch module systems on the fly (aka with ES6 a standardized module system was finally introduced) I have started to work on it on a github project this summer... but I never publicly announced it since the entire thing is not in a representable state yet. What I would propose is following: a) Fix the old codebase for JSF 2.3 b) Lets reimplement the stuff in Typescript with a bunch of helpers from modern libs like a dom query engine and Promise shims and drop really old browser support along the way - so that we can offer the new codebase sometime along jsf 2.3. c) Drop the old codebase for JSF 2.4 was (Author: werpu): Hi I am a little bit bound by other things this week, (one of them is to get out another ext-scripting release), I will to get back to you sometime next week. I think AjaxResponse22 is not really workable code, I need to check it - it should not have made it into the codebase, I think. But take this with a grain of salt it has been a while. In any way, the viewstate handling has been altered for jsf 2.3, we need to fix this in our code, there was no fix without breaking existing code. In the long run we should replace the existing javascripts since it is rather old. There is a load of code in there which is obsolete: Also we need to add Websockets, which is also part of the JSF 2.3 js part. (I need to look into that) a) We use our own class system based in prototype b) We support stone old browsers, we should ramp it up to IE9 as baseline I guess, I wonder if anyone still uses any IE below that in a corporate environment? c) We might rewrite the code in Typescript for maintainability reasons, this would allow us to ramp up the Ecmascript level dynamically and also to switch module systems on the fly (aka with ES6 a standardized module system was finally introduced) I have started to work on it on a github project this summer... but I never publicly announced it since the entire thing is not in a representable state yet. What I would propose is following: a) Fix the old codebase for JSF 2.3 b) Lets reimplement the stuff in Typescript with a bunch of helpers from modern libs like a dom query engine and Promise shims and drop really old browser support along the way - so that we can offer the new codebase sometime along jsf 2.3. c) Drop the old codebase for JSF 2.4 > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183744#comment-16183744 ] Werner Punz edited comment on MYFACES-4160 at 9/28/17 6:37 AM: --- Hi I am a little bit bound by other things this week, (one of them is to get out another ext-scripting release), I will to get back to you sometime next week. I think AjaxResponse22 is not really workable code, I need to check it - it should not have made it into the codebase, I think. But take this with a grain of salt it has been a while. In any way, the viewstate handling has been altered for jsf 2.3, we need to fix this in our code, there was no fix without breaking existing code. In the long run we should replace the existing javascripts since it is rather old. There is a load of code in there which is obsolete: Also we need to add Websockets, which is also part of the JSF 2.3 js part. (I need to look into that) a) We use our own class system based in prototype b) We support stone old browsers, we should ramp it up to IE9 as baseline I guess, I wonder if anyone still uses any IE below that in a corporate environment? c) We might rewrite the code in Typescript for maintainability reasons, this would allow us to ramp up the Ecmascript level dynamically and also to switch module systems on the fly (aka with ES6 a standardized module system was finally introduced) I have started to work on it on a github project this summer... but I never publicly announced it since the entire thing is not in a representable state yet. What I would propose is following: a) Fix the old codebase for JSF 2.3 b) Lets reimplement the stuff in Typescript with a bunch of helpers from modern libs like a dom query engine and Promise shims and drop really old browser support along the way - so that we can offer the new codebase sometime along jsf 2.3. c) Drop the old codebase for JSF 2.4 was (Author: werpu): Hi I am a little bit bound by other things this week, (one of them is to get out another ext-scripting release), I will to get back to you sometime next week. I think AjaxResponse22 is not really workable code, I need to check it. In any way, the viewstate handling has been altered for jsf 2.3, we need to fix this in our code, there was no fix without breaking existing code. In the long run we should replace the existing javascripts since it is rather old. There is a load of code in there which is obsolete: Also we need to add Websockets, which is also part of the JSF 2.3 js part. (I need to look into that) a) We use our own class system based in prototype b) We support stone old browsers, we should ramp it up to IE9 as baseline I guess, I wonder if anyone still uses any IE below that in a corporate environment? c) We might rewrite the code in Typescript for maintainability reasons, this would allow us to ramp up the Ecmascript level dynamically and also to switch module systems on the fly (aka with ES6 a standardized module system was finally introduced) I have started to work on it on a github project this summer... but I never publicly announced it since the entire thing is not in a representable state yet. What I would propose is following: a) Fix the old codebase for JSF 2.3 b) Lets reimplement the stuff in Typescript with a bunch of helpers from modern libs like a dom query engine and Promise shims and drop really old browser support along the way - so that we can offer the new codebase sometime along jsf 2.3. c) Drop the old codebase for JSF 2.4 > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183744#comment-16183744 ] Werner Punz edited comment on MYFACES-4160 at 9/28/17 6:37 AM: --- Hi I am a little bit bound by other things this week, (one of them is to get out another ext-scripting release), I will to get back to you sometime next week. I think AjaxResponse22 is not really workable code, I need to check it. In any way, the viewstate handling has been altered for jsf 2.3, we need to fix this in our code, there was no fix without breaking existing code. In the long run we should replace the existing javascripts since it is rather old. There is a load of code in there which is obsolete: Also we need to add Websockets, which is also part of the JSF 2.3 js part. (I need to look into that) a) We use our own class system based in prototype b) We support stone old browsers, we should ramp it up to IE9 as baseline I guess, I wonder if anyone still uses any IE below that in a corporate environment? c) We might rewrite the code in Typescript for maintainability reasons, this would allow us to ramp up the Ecmascript level dynamically and also to switch module systems on the fly (aka with ES6 a standardized module system was finally introduced) I have started to work on it on a github project this summer... but I never publicly announced it since the entire thing is not in a representable state yet. What I would propose is following: a) Fix the old codebase for JSF 2.3 b) Lets reimplement the stuff in Typescript with a bunch of helpers from modern libs like a dom query engine and Promise shims and drop really old browser support along the way - so that we can offer the new codebase sometime along jsf 2.3. c) Drop the old codebase for JSF 2.4 was (Author: werpu): Hi I am a little bit bound by other things this week, (one of them is to get out another ext-scripting release), I will to get back to you sometime next week. I think AjaxResponse22 is not really workable code, I need to check it. In any way, the viewstate handling has been altered for jsf 2.3, we need to fix this in our code, there was no fix without breaking existing code. In the long run we should replace the existing javascripts since it is rather old. There is a load of code in there which is obsolete: Also we need to add Websockets, which is also part of the JSF 2.3 js part. (I need to look into that) a) We use our own class system based in prototype b) We support stone old browsers, we should ramp it up to IE9 as baseline I guess, I wonder if anyone still uses any IE below that in a corporate environment? c) We might rewrite the code in Typescript for maintainability reasons, this would allow us to ramp up the Ecmascript level dynamically and also to switch module systems on the fly (aka with ES6 a standardized module system was finally introduced) I have started to work on it on a github project this summer... but I never publicly announced it since the entire thing is not in a representable state yet. What I would propose is following: a) Fix the old codebase for JSF 2.3 b) Lets reimplement the stuff in Typescript with a bunch of helpers from modern libs like a dom query engine and Promise shims and drop really old browser support along the way. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183744#comment-16183744 ] Werner Punz edited comment on MYFACES-4160 at 9/28/17 6:36 AM: --- Hi I am a little bit bound by other things this week, (one of them is to get out another ext-scripting release), I will to get back to you sometime next week. I think AjaxResponse22 is not really workable code, I need to check it. In any way, the viewstate handling has been altered for jsf 2.3, we need to fix this in our code, there was no fix without breaking existing code. In the long run we should replace the existing javascripts since it is rather old. There is a load of code in there which is obsolete: Also we need to add Websockets, which is also part of the JSF 2.3 js part. (I need to look into that) a) We use our own class system based in prototype b) We support stone old browsers, we should ramp it up to IE9 as baseline I guess, I wonder if anyone still uses any IE below that in a corporate environment? c) We might rewrite the code in Typescript for maintainability reasons, this would allow us to ramp up the Ecmascript level dynamically and also to switch module systems on the fly (aka with ES6 a standardized module system was finally introduced) I have started to work on it on a github project this summer... but I never publicly announced it since the entire thing is not in a representable state yet. What I would propose is following: a) Fix the old codebase for JSF 2.3 b) Lets reimplement the stuff in Typescript with a bunch of helpers from modern libs like a dom query engine and Promise shims and drop really old browser support along the way. was (Author: werpu): Hi I am a little bit bound by other things this week, (one of them is to get out another ext-scripting release), I will to get back to you sometime next week. I think AjaxResponse22 is not really workable code, I need to check it. In any way, the viewstate handling has been altered for jsf 2.3, we need to fix this in our code, there was no fix without breaking existing code. In the long run we should replace the existing javascripts since it is rather old. There is a load of code in there which is obsolete: Also we need to add Websockets, which is also part of the JSF 2.3 js part. (I need to look into that) a) We use our own class system based in prototype b) We support stone old browsers, we should ramp it up to IE9 as baseline I guess, I wonder if anyone still uses any IE below that in a corporate environment? c) We might rewrite the code in Typescript for maintainability reasons, this would allow us to ramp up the Ecmascript level dynamically and also to switch module systems on the fly (aka with ES6 a standardized module system was finally introduced) I have started to work on it on a github project this summer... but I never publicly announced it since the entire thing is not in a representable state yet. What I would propose is following: a) Fix the old codebase for JSF 2.3 b) Lets reimplement the stuff in Typescript with a bunch of helpers from modern libs and drop really old browser support along the way. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request
[ https://issues.apache.org/jira/browse/MYFACES-4160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16183102#comment-16183102 ] Thomas Andraschko edited comment on MYFACES-4160 at 9/27/17 7:19 PM: - Checked that case again and i remember now that the forms were always rendered without viewstate id and was applied via JS. Now looking why it doesn't work - Somehow we also have 2 AjaxResponse.js. Seems like AjaxResponse.js instead AjaxResponse22.js is used, we definitely need a cleanup here. was (Author: tandraschko): Checked that case again and i remember now that the forms were always rendered without viewstate id and was applied via JS. Now looking why it doesn't work - Somehow we also have 2 AjaxResponse.js. > ViewState not written for Ajax request > -- > > Key: MYFACES-4160 > URL: https://issues.apache.org/jira/browse/MYFACES-4160 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.3.0-beta >Reporter: Thomas Andraschko > Fix For: 2.3.0 > > > If you run the application from MYFACES-4156 via mvn jetty:run, the > viewStateId isn't rendered again after the first ajax request. > Seems like FaceletViewDeclerationLanguage line 1910 should handle that but it > skips. > [~lu4242] Could you please check that? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
