[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Leonardo Uribe (JIRA)]

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

Leonardo Uribe commented on MYFACES-4162:
-

I'm still here. Just don't have enough time to contribute these days.

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Werner Punz (JIRA)]

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

Werner Punz commented on MYFACES-4162:
--

Yeah I noticed. I will ask around what happened to him.
He used to be on Irians payroll just for myfaces.


> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4154) The browser (chrome) always show the previous page name while its on the current page rendered properly

[Werner Punz (JIRA)]

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

Werner Punz commented on MYFACES-4154:
--

Upping the bug to major, since the navigational code is vital and if we have a 
bug there we need to investigate before the final 2.3 release.


> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly
> ---
>
> Key: MYFACES-4154
> URL: https://issues.apache.org/jira/browse/MYFACES-4154
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
> Attachments: mf23test.zip
>
>
> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly . This bug is already logged in jira not sure 
> of the bug id. Not sure its browser problem  or jsf. Not checked this with 
> mojarra also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4154) The browser (chrome) always show the previous page name while its on the current page rendered properly

[Werner Punz (JIRA)]

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

Werner Punz edited comment on MYFACES-4154 at 10/9/17 5:02 PM:
---

Adding the comment from 4162

I just checked the usecase, that is unrelated to the ajax code.
Following, the login page makes an ajax navigation. The response sends a 
viewstate of:


]]>

which apparently ends up in the form as following element:



As you can see a perfectly valid viewstate
Now the logout button is a normal non ajaxed button






where the logout button is in ui:include:



now what happens if i press the first signout, I end up back on the same page 
apparently something in the myfaces 2.3 navigational code is messed up here, 
but not on the ajax side. Either the server sends a wrong viewstate back at the 
ajax request or something else is broken in this usecase.

By pressing the button a second time I finally have the correct viewstate and 
the navigation goes forward back to the login page.
Sorry there is nothing I can do on my side here, the viewstates coming in from 
the server are correctly inserted. The server guys need to debug that out.

Just a sidenote, I replaced quickly our implementation in the pom.xml with the 
mojarra binaries. Mojarra 2.3.2 navigates correctly.


was (Author: werpu):
Adding the comment from 4162

I just checked the usecase, that is unrelated to the ajax code.
Following, the login page makes an ajax navigation. The response sends a 
viewstate of:


]]>
which apparently ends up in the form as following element:


As you can see a perfectly valid viewstate
Now the logout button is a normal non ajaxed button






where the logout button is in ui:include:



now what happens if i press the first signout, I end up back on the same page 
apparently something in the myfaces 2.3 navigational code is messed up here, 
but not on the ajax side. Either the server sends a wrong viewstate back at the 
ajax request or something else is broken in this usecase.

By pressing the button a second time I finally have the correct viewstate and 
the navigation goes forward back to the login page.
Sorry there is nothing I can do on my side here, the viewstates coming in from 
the server are correctly inserted. The server guys need to debug that out.

Just a sidenote, I replaced quickly our implementation in the pom.xml with the 
mojarra binaries. Mojarra 2.3.2 navigates correctly.

> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly
> ---
>
> Key: MYFACES-4154
> URL: https://issues.apache.org/jira/browse/MYFACES-4154
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
>Priority: Minor
> Attachments: mf23test.zip
>
>
> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly . This bug is already logged in jira not sure 
> of the bug id. Not sure its browser problem  or jsf. Not checked this with 
> mojarra also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Thomas Andraschko (JIRA)]

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

Thomas Andraschko commented on MYFACES-4162:


All right. I will try to have a look at this. Leo seems away since some 
weeks/months.

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4154) The browser (chrome) always show the previous page name while its on the current page rendered properly

[Werner Punz (JIRA)]

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

Werner Punz commented on MYFACES-4154:
--

Adding the comment from 4162

I just checked the usecase, that is unrelated to the ajax code.
Following, the login page makes an ajax navigation. The response sends a 
viewstate of:


]]>
which apparently ends up in the form as following element:


As you can see a perfectly valid viewstate
Now the logout button is a normal non ajaxed button






where the logout button is in ui:include:



now what happens if i press the first signout, I end up back on the same page 
apparently something in the myfaces 2.3 navigational code is messed up here, 
but not on the ajax side. Either the server sends a wrong viewstate back at the 
ajax request or something else is broken in this usecase.

By pressing the button a second time I finally have the correct viewstate and 
the navigation goes forward back to the login page.
Sorry there is nothing I can do on my side here, the viewstates coming in from 
the server are correctly inserted. The server guys need to debug that out.

Just a sidenote, I replaced quickly our implementation in the pom.xml with the 
mojarra binaries. Mojarra 2.3.2 navigates correctly.

> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly
> ---
>
> Key: MYFACES-4154
> URL: https://issues.apache.org/jira/browse/MYFACES-4154
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
>Priority: Minor
> Attachments: mf23test.zip
>
>
> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly . This bug is already logged in jira not sure 
> of the bug id. Not sure its browser problem  or jsf. Not checked this with 
> mojarra also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4154) The browser (chrome) always show the previous page name while its on the current page rendered properly

[Werner Punz (JIRA)]

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

Werner Punz commented on MYFACES-4154:
--

I investigated the issue, this seems like a wrong viewstate problem on the 
server triggered by an ajax navigational case.
See my comment regarding it in:

https://issues.apache.org/jira/browse/MYFACES-4162

The problem definitely is on the server side not the client side here.


> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly
> ---
>
> Key: MYFACES-4154
> URL: https://issues.apache.org/jira/browse/MYFACES-4154
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Dora Rajappan
>Priority: Minor
> Attachments: mf23test.zip
>
>
> The browser (chrome) always show the previous page name while its on the 
> current page rendered properly . This bug is already logged in jira not sure 
> of the bug id. Not sure its browser problem  or jsf. Not checked this with 
> mojarra also.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Werner Punz (JIRA)]

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

Werner Punz commented on MYFACES-4162:
--

I just checked the usecase, that is unrelated to the ajax code.
Following, the login page makes an ajax navigation. The response sends a 
viewstate of:
  


]]>


which apparently ends up in the form as following element:



As you can see a perfectly valid viewstate

Now the logout button is a normal non ajaxed button

 

  


where the logout button is in ui:include:

  

 
now what happens if i press the first signout, I end up back on the same page 
apparently something in the myfaces 2.3 navigational code is messed up here, 
but not on the ajax side. Either the server sends a wrong viewstate back at the 
ajax request or something else is broken in this usecase.
By pressing the button a second time I finally have the correct viestate and 
the navigation goes forward back to the login page.

Sorry there is nothing I can do on my side here, the viewstates coming in from 
the server are correctly inserted. The server guys need to debug that out.
Just a sidenote, I replaced quickly our implementation in the pom.xml with 
mojarra. Mojarra 2.3.2 navigates correctly.






> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Thomas Andraschko (JIRA)]

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

Thomas Andraschko commented on MYFACES-4162:


So https://issues.apache.org/jira/projects/MYFACES/issues/MYFACES-4154 is also 
fixed?

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Werner Punz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/MYFACES-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Werner Punz resolved MYFACES-4162.
--
Resolution: Resolved

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Werner Punz (JIRA)]

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

Werner Punz commented on MYFACES-4162:
--

so fixed in 1811580 apparently, there were some smaller javascript errors which 
slipped through my unit tests.
The example from Dora now works here as expected. The viewroot is properly 
resolved and the elements updated, the viewstate
is attached later on as expected.


> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Werner Punz (JIRA)]

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

Werner Punz commented on MYFACES-4162:
--

Actually it seems to be a slight js error on my side in the new code.
The browser bombs out because of a wrong js function call into the string 
length. Will fix that quickly.


> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Werner Punz (JIRA)]

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

Werner Punz edited comment on MYFACES-4162 at 10/9/17 2:36 PM:
---

Actually on the response side it looks ok
javax.faces.ViewRoot is the update id which means both head and body need to be 
replaced, which the code does.

I just need to check what happens on the client side.
The javax.faces.ViewRoot is a valid response for this case it is within the 
bounds of the jsf.ajax response protocol so no need to fix anything on the 
server here.



was (Author: werpu):
Actually on the response side it looks ok
javax.faces.ViewRoot is the update id which means both head and body need to be 
replaced, which the code does.

I just need to check what happens on the client side.


> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Werner Punz (JIRA)]

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

Werner Punz commented on MYFACES-4162:
--

Actually on the response side it looks ok
javax.faces.ViewRoot is the update id which means both head and body need to be 
replaced, which the code does.

I just need to check what happens on the client side.


> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Dora Rajappan (JIRA)]

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

Dora Rajappan commented on MYFACES-4162:


Works fine with IE and not with chrome!

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Thomas Andraschko (JIRA)]

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

Thomas Andraschko edited comment on MYFACES-4162 at 10/9/17 2:33 PM:
-

so the navigation is triggered but not via redirect (e.g. ?faces-redirect=true)?
Does the server return a update id="javax.faces.ViewRoot"? (It also happens 
when using update=@all)


was (Author: tandraschko):
so the navigation is triggered but not via redirect (e.g. ?faces-redirect=true)?
Does the server return a update id="javax.faces.ViewRoot"?

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Thomas Andraschko (JIRA)]

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

Thomas Andraschko commented on MYFACES-4162:


so the navigation is triggered but not via redirect (e.g. ?faces-redirect=true)?
Does the server return a update id="javax.faces.ViewRoot"?

> bug in the response handling if a full page is sent via ajax
> 
>
> Key: MYFACES-4162
> URL: https://issues.apache.org/jira/browse/MYFACES-4162
> Project: MyFaces Core
>  Issue Type: Bug
>Affects Versions: 2.3.0-beta
>Reporter: Werner Punz
>Assignee: Werner Punz
>
> The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back 
> an entire page due to a page navigation triggered from an ajax call, and 
> apparently the page is inserted but the viewstate is lost along the way. I 
> need to investigate what happens for such a corner case, since triggering a 
> page change navigation from Ajax is rather seldom but needs to be addressed.
> I will need a handful of days to fix this, due to my limited time.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MYFACES-4162) bug in the response handling if a full page is sent via ajax

[Werner Punz (JIRA)]

Werner Punz created MYFACES-4162:


 Summary: bug in the response handling if a full page is sent via 
ajax
 Key: MYFACES-4162
 URL: https://issues.apache.org/jira/browse/MYFACES-4162
 Project: MyFaces Core
  Issue Type: Bug
Affects Versions: 2.3.0-beta
Reporter: Werner Punz
Assignee: Werner Punz


The example in https://issues.apache.org/jira/browse/MYFACES-4154 sends back an 
entire page due to a page navigation triggered from an ajax call, and 
apparently the page is inserted but the viewstate is lost along the way. I need 
to investigate what happens for such a corner case, since triggering a page 
change navigation from Ajax is rather seldom but needs to be addressed.

I will need a handful of days to fix this, due to my limited time.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: jsf.js post 2.3 plans

[Dora Rajappan]

  Hi Werner,
     I had a mvn clean package of core and checked it from IE 11 and it works 
very good.     The fix works fine with repeated ajax calls now!  
 Thanks & Regards, Dora Rajappan.
   
.On Monday, October 9, 2017, 3:19:19 PM GMT+5:30, Werner Punz 
 wrote:  
 
 Just to clarify it:

Before the update it looks like

https://gist.github.com/werpu/ 071e11cc6328f9f439a6342b0e128e c8

Both forms have a viewstate element.

Before my fixes, the viewstate of the first form was gone.
Hence you ran into issues:

After my yesterdays update the result now looks like following (I got a 
validation error so the viewstate is recycled in the response which 
looks like)

https://gist.github.com/werpu/ 172786afcdf6514b6120379ab5e236 ce

The final rendered form is now:

https://gist.github.com/werpu/ cd85343ddc42ef8857a806d8fe06e2 33


EjSU7V49OrNPDglILvevt4kDdHyuyO RwVxrmPKQfWqfKBXoi on form 1 and 2 being 
the same.


Before my patches, only the second form hat a valid viewstate element 
set and hence you ran into viewstate issues.

Please check the jsf.js your browser is loading, if you got the old 
version in, it looks like it. The build should have produced one
with the new version, but jsf.js is never checked in, it is built by the 
build system.

Check your browsers jsf.js for something like mfInternal.namingModeId
This is only in my patch but not in the old codebase.



Cheers

Werner




Am 09.10.17 um 11:34 schrieb Werner Punz:
> Hi Dora, what do you mean that the
> behavior of repeated ajax calls is same?
> 
> 
> I tried your example yesterday after building the final js file via a 
> mvn build and before
> only the second form got an ajax viestate update
> now both forms get one.
> 
> What behavior do you get?
> Did you make a proper mvn clean install to get the latest jsf.js in?
> 
> ajaxresponse22.js was deleted because it is dead code it accidentally 
> was in the codebase, ajaxresponse.js now updates all forms in a 
> multiform environment under a given view root. In your example
> the viewroot is the body element.
> 
> 
> 
> 
> 
> Werner
> 
> 
> 
> Am 09.10.17 um 10:46 schrieb Dora Rajappan:
>> Hi,
>>
>>   Thank you very much for the fix Werner.
>>   I took the latest core today and built it and tested from payara 
>> without any config changes. Found ajaxresponse22.js deleted and 
>> ajaxresponse.js changed.
>>   And the behavior of repeated ajax calls is same.
>>   Can we have the config changes exactly if any in this manner? I 
>> checked 4160 and quickly not make out the config changes.
>>     
>>          xyz
>>          abc
>>      
>>
>> Thanks & Regards,
>> Dora Rajappan.
>> On Sunday, October 8, 2017, 7:39:48 PM GMT+5:30, Werner Punz 
>>  wrote:
>>
>>
>> No sync with Mojarra I have discussed that a while ago.
>> The problem is a licensing problem. Mojarra basically can use
>> our code but not vice versa, because the CDDL cannot be implemented in
>> ASF2 code.
>>
>> The ASF2 license is a very liberal license, but due to the fact that it
>> is so liberal, it is impossible to integrate less liberal code in our
>> codebase.
>>
>> As for your repeated Ajax problems MYFACES-4160 that is a really old
>> spec bug which reared its ugly head in multiform scenarii.
>> I worked around that by providing a special config param.
>> With JSF 2.3 it finally will be fixed.
>>
>>
>>
>> Werner
>>
>>
>> Am 06.10.17 um 11:59 schrieb Dora Rajappan:
>>  > Thanks for detailing the future of browser and how jsf cope up with 
>> it.
>>  >
>>  > I was using mojarra for my application and the commandLink was not
>>  > working due to script problem.
>>  > So I switched to myfaces and we got some problem with repeated ajax
>>  > calls. (Myfaces 4160).
>>  >
>>  > Are we syncing with mojarra regarding the technology to be used 
>> with the
>>  > jsf.js, entire scripting arena.
>>  > Not sure spec say anything about the technology used for scripting.
>>  >
>>  > Thanks & Regards,
>>  > Dora Rajappan.
>>
>>
> 
> 
> 


  

  

[jira] [Commented] (TOBAGO-1810) Create a markup for expanding tc:bar

[Hudson (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOBAGO-1810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196768#comment-16196768
 ] 

Hudson commented on TOBAGO-1810:


SUCCESS: Integrated in Jenkins build Tobago Trunk #1065 (See 
[https://builds.apache.org/job/Tobago%20Trunk/1065/])
TOBAGO-1810 Create a markup for expanding tc:bar * implement markups (hnoeth: 
rev e7b006bf4c5d9f91df7aa980eed5009e954445a3)
* (edit) 
tobago-core/src/main/java/org/apache/myfaces/tobago/internal/renderkit/renderer/BarRenderer.java
* (edit) 
tobago-core/src/main/java/org/apache/myfaces/tobago/renderkit/css/BootstrapClass.java
* (edit) tobago-core/src/main/java/org/apache/myfaces/tobago/context/Markup.java
* (edit) 
tobago-example/tobago-example-demo/src/main/webapp/content/20-component/050-container/60-bar/bar.xhtml
* (edit) 
tobago-example/tobago-example-demo/src/main/webapp/content/10-intro/50-migration/96-migration/migration40.xhtml


> Create a markup for expanding tc:bar
> 
>
> Key: TOBAGO-1810
> URL: https://issues.apache.org/jira/browse/TOBAGO-1810
> Project: MyFaces Tobago
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 3.0.6
>Reporter: Henning Noeth
>Assignee: Henning Noeth
> Fix For: 4.0.0
>
>
> Since Bootstrap Beta,  needs a custom class set: 
> navbar-expand-{sm|md|lg|xl}
> This should be done by markups.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: jsf.js post 2.3 plans

[Werner Punz]

Just to clarify it:

Before the update it looks like

https://gist.github.com/werpu/071e11cc6328f9f439a6342b0e128ec8

Both forms have a viewstate element.

Before my fixes, the viewstate of the first form was gone.
Hence you ran into issues:

After my yesterdays update the result now looks like following (I got a 
validation error so the viewstate is recycled in the response which 
looks like)


https://gist.github.com/werpu/172786afcdf6514b6120379ab5e236ce

The final rendered form is now:

https://gist.github.com/werpu/cd85343ddc42ef8857a806d8fe06e233


EjSU7V49OrNPDglILvevt4kDdHyuyORwVxrmPKQfWqfKBXoi on form 1 and 2 being 
the same.



Before my patches, only the second form hat a valid viewstate element 
set and hence you ran into viewstate issues.


Please check the jsf.js your browser is loading, if you got the old 
version in, it looks like it. The build should have produced one
with the new version, but jsf.js is never checked in, it is built by the 
build system.


Check your browsers jsf.js for something like mfInternal.namingModeId
This is only in my patch but not in the old codebase.



Cheers

Werner




Am 09.10.17 um 11:34 schrieb Werner Punz:

Hi Dora, what do you mean that the
behavior of repeated ajax calls is same?


I tried your example yesterday after building the final js file via a 
mvn build and before

only the second form got an ajax viestate update
now both forms get one.

What behavior do you get?
Did you make a proper mvn clean install to get the latest jsf.js in?

ajaxresponse22.js was deleted because it is dead code it accidentally 
was in the codebase, ajaxresponse.js now updates all forms in a 
multiform environment under a given view root. In your example

the viewroot is the body element.





Werner



Am 09.10.17 um 10:46 schrieb Dora Rajappan:

Hi,

  Thank you very much for the fix Werner.
  I took the latest core today and built it and tested from payara 
without any config changes. Found ajaxresponse22.js deleted and 
ajaxresponse.js changed.

  And the behavior of repeated ajax calls is same.
  Can we have the config changes exactly if any in this manner? I 
checked 4160 and quickly not make out the config changes.

    
         xyz
         abc
     

Thanks & Regards,
Dora Rajappan.
On Sunday, October 8, 2017, 7:39:48 PM GMT+5:30, Werner Punz 
 wrote:



No sync with Mojarra I have discussed that a while ago.
The problem is a licensing problem. Mojarra basically can use
our code but not vice versa, because the CDDL cannot be implemented in
ASF2 code.

The ASF2 license is a very liberal license, but due to the fact that it
is so liberal, it is impossible to integrate less liberal code in our
codebase.

As for your repeated Ajax problems MYFACES-4160 that is a really old
spec bug which reared its ugly head in multiform scenarii.
I worked around that by providing a special config param.
With JSF 2.3 it finally will be fixed.



Werner


Am 06.10.17 um 11:59 schrieb Dora Rajappan:
 > Thanks for detailing the future of browser and how jsf cope up with 
it.

 >
 > I was using mojarra for my application and the commandLink was not
 > working due to script problem.
 > So I switched to myfaces and we got some problem with repeated ajax
 > calls. (Myfaces 4160).
 >
 > Are we syncing with mojarra regarding the technology to be used 
with the

 > jsf.js, entire scripting arena.
 > Not sure spec say anything about the technology used for scripting.
 >
 > Thanks & Regards,
 > Dora Rajappan.

Re: jsf.js post 2.3 plans

[Werner Punz]

Hi Dora, what do you mean that the
behavior of repeated ajax calls is same?


I tried your example yesterday after building the final js file via a 
mvn build and before

only the second form got an ajax viestate update
now both forms get one.

What behavior do you get?
Did you make a proper mvn clean install to get the latest jsf.js in?

ajaxresponse22.js was deleted because it is dead code it accidentally 
was in the codebase, ajaxresponse.js now updates all forms in a 
multiform environment under a given view root. In your example

the viewroot is the body element.





Werner



Am 09.10.17 um 10:46 schrieb Dora Rajappan:

Hi,

  Thank you very much for the fix Werner.
  I took the latest core today and built it and tested from payara 
without any config changes. Found ajaxresponse22.js deleted and 
ajaxresponse.js changed.

  And the behavior of repeated ajax calls is same.
  Can we have the config changes exactly if any in this manner? I 
checked 4160 and quickly not make out the config changes.

    
         xyz
         abc
     

Thanks & Regards,
Dora Rajappan.
On Sunday, October 8, 2017, 7:39:48 PM GMT+5:30, Werner Punz 
 wrote:



No sync with Mojarra I have discussed that a while ago.
The problem is a licensing problem. Mojarra basically can use
our code but not vice versa, because the CDDL cannot be implemented in
ASF2 code.

The ASF2 license is a very liberal license, but due to the fact that it
is so liberal, it is impossible to integrate less liberal code in our
codebase.

As for your repeated Ajax problems MYFACES-4160 that is a really old
spec bug which reared its ugly head in multiform scenarii.
I worked around that by providing a special config param.
With JSF 2.3 it finally will be fixed.



Werner


Am 06.10.17 um 11:59 schrieb Dora Rajappan:
 > Thanks for detailing the future of browser and how jsf cope up with it.
 >
 > I was using mojarra for my application and the commandLink was not
 > working due to script problem.
 > So I switched to myfaces and we got some problem with repeated ajax
 > calls. (Myfaces 4160).
 >
 > Are we syncing with mojarra regarding the technology to be used with the
 > jsf.js, entire scripting arena.
 > Not sure spec say anything about the technology used for scripting.
 >
 > Thanks & Regards,
 > Dora Rajappan.

Re: jsf.js post 2.3 plans

[Dora Rajappan]

 Hi,
 Thank you very much for the fix Werner. I took the latest core today and built 
it and tested from payara without any config changes. Found ajaxresponse22.js 
deleted and ajaxresponse.js changed. And the behavior of repeated ajax calls is 
same. Can we have the config changes exactly if any in this manner? I checked 
4160 and quickly not make out the config changes.            
xyz        abc            

Thanks & Regards,Dora Rajappan.On Sunday, October 8, 2017, 7:39:48 PM 
GMT+5:30, Werner Punz  wrote:  
 
 No sync with Mojarra I have discussed that a while ago.
The problem is a licensing problem. Mojarra basically can use
our code but not vice versa, because the CDDL cannot be implemented in 
ASF2 code.

The ASF2 license is a very liberal license, but due to the fact that it 
is so liberal, it is impossible to integrate less liberal code in our 
codebase.

As for your repeated Ajax problems MYFACES-4160 that is a really old 
spec bug which reared its ugly head in multiform scenarii.
I worked around that by providing a special config param.
With JSF 2.3 it finally will be fixed.



Werner


Am 06.10.17 um 11:59 schrieb Dora Rajappan:
> Thanks for detailing the future of browser and how jsf cope up with it.
> 
> I was using mojarra for my application and the commandLink was not 
> working due to script problem.
> So I switched to myfaces and we got some problem with repeated ajax 
> calls. (Myfaces 4160).
> 
> Are we syncing with mojarra regarding the technology to be used with the 
> jsf.js, entire scripting arena.
> Not sure spec say anything about the technology used for scripting.
> 
> Thanks & Regards,
> Dora Rajappan.

Re: JSF 2.3 some minor questions regarding jsf.js

[Werner Punz]

Ok thanks for the clarification.

Cheers

Werner

All my fixes are pushed, give it a proper beating.



Am 08.10.17 um 17:06 schrieb Thomas Andraschko:

Hi,

cool +1!

1) yep, push should be already done

2) the server should already only render real new resources, if it's not 
happening, we should fix it on the server side

[jira] [Comment Edited] (MYFACES-4160) ViewState not written for Ajax request

[Werner Punz (JIRA)]

[ 
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] [Commented] (MYFACES-4160) ViewState not written for Ajax request

[Werner Punz (JIRA)]

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

Werner Punz commented on MYFACES-4160:
--

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] [Created] (TOBAGO-1814) Create markups for light / dark tc:bar

[Henning Noeth (JIRA)]

Henning Noeth created TOBAGO-1814:
-

 Summary: Create markups for light / dark tc:bar
 Key: TOBAGO-1814
 URL: https://issues.apache.org/jira/browse/TOBAGO-1814
 Project: MyFaces Tobago
  Issue Type: New Feature
  Components: Core
Affects Versions: 3.0.6
Reporter: Henning Noeth
Assignee: Henning Noeth


Since Bootstrap Beta,  needs a custom class:
- 'navbar-light' for light backgrounds
- 'navbar-dark' for dark background
This should be done by markups.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MYFACES-4160) ViewState not written for Ajax request

[Thomas Andraschko (JIRA)]

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

Thomas Andraschko commented on MYFACES-4160:


Thanks werner!
So my example app is also working now?

> 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] [Commented] (EXTSCRIPT-188) Extension don't works on Myfaces 2.2.3 / 2.2.11

[Werner Punz (JIRA)]

[ 
https://issues.apache.org/jira/browse/EXTSCRIPT-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196557#comment-16196557
 ] 

Werner Punz commented on EXTSCRIPT-188:
---

The config should be ok... the examples are basically wont work out of the box, 
you need to adjust the web.xmls paths according to your machine.

Check the embedded web.xml there is a huge section commented out which needs to 
be adapted before running the examples.


> Extension don't works on Myfaces 2.2.3 / 2.2.11
> ---
>
> Key: EXTSCRIPT-188
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-188
> Project: MyFaces Extensions Scripting
>  Issue Type: Bug
>  Components: MyFaces 2.0 Extension
>Affects Versions: 1.0.6-FINAL
> Environment: Debian 8.2
> JDK 1.8
> Tomcat 7.0.42
>Reporter: NCister
>Assignee: Werner Punz
> Fix For: 1.0.6-SNAPSHOT, 1.0.6-FINAL
>
>
> Trying to follow example config 
> (http://myfaces.apache.org/extensions/scripting/exampleconfig.html) I've 
> noticed that the web.xml settings are wrong so:
> org.apache.myfaces.FACES_INIT_PLUGINS
> org.apache.myfaces.extensions.scripting.servlet.StartupServletContextPluginChainLoader
> must be updated to:
> ...
> org.apache.myfaces.extensions.scripting.jsf.startup.StartupServletContextPluginChainLoader
> ...
> Again: The example war 
> (https://repository.apache.org/content/repositories/releases/org/apache/myfaces/extensions/scripting/myfaces20-extscript-helloworld/1.0.5/myfaces20-extscript-helloworld-1.0.5.war)
>  deployed in a clean tomcat 7.0 instance) don't works (no errors, no results 
> ...)
> Does Groovy integration works in MyFaces 2.2 ?
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: jsf.js post 2.3 plans

[Werner Punz]

Ok just to FUP... To give food for discussion:

I gave kotlin a few minutes ago a testrun, here is the result:

package test.test2



class TestClass {

val hello: String = "";


fun helloWorld() {
console.info("hello");
}

}


and the resulting Javascript was:

if (typeof kotlin === 'undefined') {
  throw new Error("Error loading module 'testkotlin'. Its dependency 
'kotlin' was not found. Please, check whether 'kotlin' is loaded prior 
to 'testkotlin'.");

}
var testkotlin = function (_, Kotlin) {
  'use strict';
  function TestClass() {
this.hello = '';
  }
  TestClass.prototype.helloWorld = function () {
console.info('hello');
  };
  TestClass.$metadata$ = {
kind: Kotlin.Kind.CLASS,
simpleName: 'TestClass',
interfaces: []
  };
  var package$test = _.test || (_.test = {});
  var package$test2 = package$test.test2 || (package$test.test2 = {});
  package$test2.TestClass = TestClass;
  Kotlin.defineModule('testkotlin', _);
  return _;
}(typeof testkotlin === 'undefined' ? {} : testkotlin, kotlin);


The problem here is that even with a simple class kotlin maps to 
kotlin,js instead of just using prototype inheritance or ES6 classes.



if (typeof kotlin === 'undefined') {
  throw new Error("Error loading module 'testkotlin'. Its dependency 
'kotlin' was not found. Please, check whether 'kotlin' is loaded prior 
to 'testkotlin'.");

}

...

var testkotlin = function (_, Kotlin) {


  TestClass.$metadata$ = {
kind: Kotlin.Kind.CLASS,
simpleName: 'TestClass',
interfaces: []
  };

Unfortunately although I am always eager to use a new language Kotlin 
for our case due to this fact is a no go:-/

Also the Kotlin.js file has about 35000 locs uncompressed.
Which is a library size which I am not very eager to bundle into a
base lib which should not interfere with other libraries and should
 be as small as possible.


Just in comparison the same code compiled from Typescript to javascript 
(ES5):


module test {
export module test2 {
export class HelloWorld {
hello: string;

helloWorld() {
console.info("hello");
}
}

}
}


var test;
(function (test) {
var test2;
(function (test2) {
var HelloWorld = (function () {
function HelloWorld() {
}
HelloWorld.prototype.helloWorld = function () {
console.info("hello");
};
return HelloWorld;
}());
test2.HelloWorld = HelloWorld;
})(test2 = test.test2 || (test.test2 = {}));
})(test || (test = {}));


A subsequent use would follow in following code:

var HelloWorld = test.test2.HelloWorld;
var hello;

So I guess the result is as clean as it can be. You can vary es levels 
and module systems just by switching the compiler settings.



The Typescript settings were compile target ES5 and no module system 
here which will be the baseline for the myfaces impl since the spec 
targets a global namespacing.


(ES6 would have produced real classes)

This is just a compiler switch away:


"use strict";
var test;
(function (test) {
var test2;
(function (test2) {
class HelloWorld {
helloWorld() {
console.info("hello");
}
}
test2.HelloWorld = HelloWorld;
})(test2 = test.test2 || (test.test2 = {}));
})(test || (test = {}));



Cheers

Werner





Am 08.10.17 um 16:09 schrieb Werner Punz:

No sync with Mojarra I have discussed that a while ago.
The problem is a licensing problem. Mojarra basically can use
our code but not vice versa, because the CDDL cannot be implemented in 
ASF2 code.


The ASF2 license is a very liberal license, but due to the fact that it 
is so liberal, it is impossible to integrate less liberal code in our 
codebase.


As for your repeated Ajax problems MYFACES-4160 that is a really old 
spec bug which reared its ugly head in multiform scenarii.

I worked around that by providing a special config param.
With JSF 2.3 it finally will be fixed.



Werner


Am 06.10.17 um 11:59 schrieb Dora Rajappan:

Thanks for detailing the future of browser and how jsf cope up with it.

I was using mojarra for my application and the commandLink was not 
working due to script problem.
So I switched to myfaces and we got some problem with repeated ajax 
calls. (Myfaces 4160).


Are we syncing with mojarra regarding the technology to be used with 
the jsf.js, entire scripting arena.

Not sure spec say anything about the technology used for scripting.

Thanks & Regards,
Dora Rajappan.

[jira] [Commented] (EXTSCRIPT-188) Extension don't works on Myfaces 2.2.3 / 2.2.11

[NCister (JIRA)]

[ 
https://issues.apache.org/jira/browse/EXTSCRIPT-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16196551#comment-16196551
 ] 

NCister commented on EXTSCRIPT-188:
---

Hi Werner.
Excuse me ... what's your test environment ? (app. server, jdk)
I've tried example war (blog-example-1.0.6, 
myfaces20-extscript-helloworld-1.0.6, ... ) in Tomcat 7.0.42 + JDK 1.7 with 
some problems...
Thanks.

> Extension don't works on Myfaces 2.2.3 / 2.2.11
> ---
>
> Key: EXTSCRIPT-188
> URL: https://issues.apache.org/jira/browse/EXTSCRIPT-188
> Project: MyFaces Extensions Scripting
>  Issue Type: Bug
>  Components: MyFaces 2.0 Extension
>Affects Versions: 1.0.6-FINAL
> Environment: Debian 8.2
> JDK 1.8
> Tomcat 7.0.42
>Reporter: NCister
>Assignee: Werner Punz
> Fix For: 1.0.6-SNAPSHOT, 1.0.6-FINAL
>
>
> Trying to follow example config 
> (http://myfaces.apache.org/extensions/scripting/exampleconfig.html) I've 
> noticed that the web.xml settings are wrong so:
> org.apache.myfaces.FACES_INIT_PLUGINS
> org.apache.myfaces.extensions.scripting.servlet.StartupServletContextPluginChainLoader
> must be updated to:
> ...
> org.apache.myfaces.extensions.scripting.jsf.startup.StartupServletContextPluginChainLoader
> ...
> Again: The example war 
> (https://repository.apache.org/content/repositories/releases/org/apache/myfaces/extensions/scripting/myfaces20-extscript-helloworld/1.0.5/myfaces20-extscript-helloworld-1.0.5.war)
>  deployed in a clean tomcat 7.0 instance) don't works (no errors, no results 
> ...)
> Does Groovy integration works in MyFaces 2.2 ?
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)