[jira] [Created] (MYFACES-3926) Disabled h:outputLink renders target attribute
Sven Linstaedt created MYFACES-3926: --- Summary: Disabled h:outputLink renders target attribute Key: MYFACES-3926 URL: https://issues.apache.org/jira/browse/MYFACES-3926 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.4 Reporter: Sven Linstaedt Priority: Trivial A disabled component renders it's content in a tag. Unfortunately the renderer does not check, if attributes that does apply to will also apply to to the tag. So in addition to common attributes like styleClass other ones are rendered, that are not valid in the context of a like: * target * tabindex * shape * rel * rev * hreflang * coords * charset * ...maybe others, but I am no export for the html spec -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TRINIDAD-2509) For date pattern=yyyy:DDD HH:mm:ss, validation error is thrown even when the date is selected from popup and is correct
[ https://issues.apache.org/jira/browse/TRINIDAD-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshu Jain updated TRINIDAD-2509: - Status: Patch Available (was: Open) > For date pattern=:DDD HH:mm:ss, validation error is thrown even when the > date is selected from popup and is correct > --- > > Key: TRINIDAD-2509 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2509 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.1.0-core > Environment: Issue occurs on all platforms >Reporter: Anshu Jain > Attachments: TRINIDAD-2509.patch > > > For a date component, the pattern is set to ":DDD HH:mm:ss". > On opening the calendar popup and selecting a date, a validation error is > thrown: > Error: The date or time entered is not valid. > The date in the date filed is in correct format at this time. But, the > validation error is incorrectly thrown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page
[ https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140257#comment-14140257 ] Nuno G. de M commented on EXTCDI-316: - Hi, and once again, I thank you both for the great input. Concerning Majorra implementation: Leo, Majorra in JSF 2.1 using server side state saving, looks at an incoming request, namely at the automatically injected input field: javax.faces.ViewState request parameter, and checks weather it is "stateless" for transient views, or if it is somelhinkg like "logicalMapKey:actualMapKey". If the thing has an actual value in there, JSF will try to recover that view, accessing a special HTTP session property where all the state is serialized. What happens is that regardless of the logical limit of CODI (64 views), by default the JSF standard will allow you only to have up to 15 records in that logical map. After that the LRU put method just knocks out the least recently entry on that map. This is a potential-critical point for issues. The gap between the size of both buffers. But I see from Gerhard's post that CODI has to abstract itself from whichever way the underlying JSF implementation is deciding to manage the view state. But Leo and Gerhard, if CODI is doing exactly what it is supposed to do, can you please clarify-me in terms of view management, what exactly are the responsabilities of CODI? - Is codi's main responsability destroying CDI beans qualified with the View Scope qualifier? Or does it go beyond that to also deal with JSF state managament? - How do you deal with the possibility that CODI can potentially support an infinite number of views per user session, and specific JSF implementation only supports three? Leaking to view destruction of view 1 as soon CODI opens the view 4 for user session? This is beyond the scope of CODI? Finally, may I then ask why the EditableWindowContextManager.close(WindowContext) seems to take a more active role in the distruction of a Window by clearing out the LRU map you use, while the WindowContext.close() seems to - i guess - only wipeout the View Scoped beans? How to projects typically end up using CODI? Say a user does not use Iframes, and accesses every page in the context of a windowId. Now the user opens a new tab which begets its own new window Id. We have now two separate WindowContexts. If the use now decides to close the new tab, those session objects and window scoped SCI beans will continue alive until the end of the user session? Many thanks. > Close window context view leakge - JSF 2.1 Multiple Iframes per page > > > Key: EXTCDI-316 > URL: https://issues.apache.org/jira/browse/EXTCDI-316 > Project: MyFaces CODI > Issue Type: Bug > Components: Core >Affects Versions: 1.0.3 > Environment: Oracle GlassFish Server 3.1.2.5 (build 2), jdk1.6.0_45 >Reporter: Nuno G. de M > Original Estimate: 72h > Remaining Estimate: 72h > > Hi, and thank you for your support. > First, I would just like to stat that I am unsure if the "issue" detected in > our application is a real issue within CODI, or if it is we that are misusing > the framework. Therefore, I would be happy to get your input on the issue I > am about to detail. > ISSUE SUMMARY: > - we have a ui architecture comprised by several Iframes within a main page, > where each iframe has its own CODI window context. After several clicks > replacing the content that of a targetIfram by new content, we were having > CODI view context leakage as well as JSF view state leakage. > ISSUE DETAILS: > For historical as well performance reasons reasons, we have a UI that is > composed into several IFrames within a parent portal iframe. This decomposing > of the view into sub-views means the JSF context to serialize-deserialize per > iframe/.xhtml present in the UI is smaller. As opposed to a single big-ui > view state. > An overview of the core iframes invovled would be: > (1) window.top - Contains the Header and a left-side navigation menu > (2) window.top.contentIfram - Iframe Contains your typical page conent > (.xhtml) > (3) window.top.footer - iframe containing a dynamic footer (its own .xhtml) > (4) wintow.top.applet - Iframe that includes an applet > (5) window.top.special - an auxiliary .xhtml that complements the applet data > (6) window.top.clean - iframe that contains an .xhtml to do CODI window > context and JSF sever state cleanup (created to deal with the issue being > explained here) > The BUG in view navigation is the following: > Each time the user interacts with the UI, e.g by clicing on an menu command > button, or on a applet view element, prompting for a new .xhtml view to be > loaded and replace the old .xhtml loaded on a target iframe we leak both a >
[jira] [Comment Edited] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page
[ https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140257#comment-14140257 ] Nuno G. de M edited comment on EXTCDI-316 at 9/19/14 9:55 AM: -- Hi, and once again, I thank you both for the great input. Concerning Majorra implementation: Leo, Majorra in JSF 2.1 using server side state saving, looks at an incoming request, namely at the automatically injected input field: javax.faces.ViewState request parameter, and checks weather it is "stateless" for transient views, or if it is somelhinkg like "logicalMapKey:actualMapKey". If the thing has an actual value in there, JSF will try to recover that view, accessing a special HTTP session property where all the state is serialized. What happens is that regardless of the logical limit of CODI (64 views), by default the JSF standard will allow you only to have up to 15 records in that logical map. After that the LRU put method just knocks out the least recently entry on that map. This is a potential-critical point for issues. The gap between the size of both buffers. But I see from Gerhard's post that CODI has to abstract itself from whichever way the underlying JSF implementation is deciding to manage the view state. But Leo and Gerhard, if CODI is doing exactly what it is supposed to do, can you please clarify-me in terms of view management, what exactly are the responsabilities of CODI? - Is codi's main responsability destroying CDI beans qualified with the View Scope qualifier? Or does it go beyond that to also deal with JSF state managament? - How do you deal with the possibility that CODI can potentially support an infinite number of views per user session, and specific JSF implementation only supports three? Leaking to view destruction of view 1 as soon CODI opens the view 4 for user session? This is beyond the scope of CODI? Finally, may I then ask why the EditableWindowContextManager.close(WindowContext) seems to take a more active role in the distruction of a Window by clearing out the LRU map you use, while the WindowContext.close() seems to - i guess - only wipeout the View Scoped beans? How to projects typically end up using CODI? Say a user does not use Iframes, and accesses every page in the context of a windowId. Now the user opens a new tab which begets its own new window Id. We have now two separate WindowContexts. If the use now decides to close the new tab, those session objects and window scoped SCI beans will continue alive until the end of the user session? Gerhard, concerning your comment about replacing the views in the client side as opposed of doing ti through typical JSF view navigation. You are correct that this does indeed lead to the creation of many more views that a typical use case. By default, when we are navigation from one .xhtml to a new one, we destroy one window and crate a new one. But this also provides an easy manner of cleaning up after beans used in that view. When you go from one page to antoher, you cleanup after all the beans that were needed before and get new fresh beans for the new view. Otherwise, assuming you don't open a second tab, you end-up with window-scoped beans that for all intents and purposes are like session scoped beans and live for longer than their real use. Many thanks. was (Author: ngdem): Hi, and once again, I thank you both for the great input. Concerning Majorra implementation: Leo, Majorra in JSF 2.1 using server side state saving, looks at an incoming request, namely at the automatically injected input field: javax.faces.ViewState request parameter, and checks weather it is "stateless" for transient views, or if it is somelhinkg like "logicalMapKey:actualMapKey". If the thing has an actual value in there, JSF will try to recover that view, accessing a special HTTP session property where all the state is serialized. What happens is that regardless of the logical limit of CODI (64 views), by default the JSF standard will allow you only to have up to 15 records in that logical map. After that the LRU put method just knocks out the least recently entry on that map. This is a potential-critical point for issues. The gap between the size of both buffers. But I see from Gerhard's post that CODI has to abstract itself from whichever way the underlying JSF implementation is deciding to manage the view state. But Leo and Gerhard, if CODI is doing exactly what it is supposed to do, can you please clarify-me in terms of view management, what exactly are the responsabilities of CODI? - Is codi's main responsability destroying CDI beans qualified with the View Scope qualifier? Or does it go beyond that to also deal with JSF state managament? - How do you deal with the possibility that CODI can potentially support an infinite number of views per user session, and specific JSF implementat
[jira] [Comment Edited] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page
[ https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140257#comment-14140257 ] Nuno G. de M edited comment on EXTCDI-316 at 9/19/14 9:57 AM: -- Hi, and once again, I thank you both for the great input. Concerning Majorra implementation: Leo, Majorra in JSF 2.1 using server side state saving, looks at an incoming request, namely at the automatically injected input field: javax.faces.ViewState request parameter, and checks weather it is "stateless" for transient views, or if it is somelhinkg like "logicalMapKey:actualMapKey". If the thing has an actual value in there, JSF will try to recover that view, accessing a special HTTP session property where all the state is serialized. What happens is that regardless of the logical limit of CODI (64 views), by default the JSF standard will allow you only to have up to 15 records in that logical map. After that the LRU put method just knocks out the least recently entry on that map. This is a potential-critical point for issues. The gap between the size of both buffers. But I see from Gerhard's post that CODI has to abstract itself from whichever way the underlying JSF implementation is deciding to manage the view state. But Leo and Gerhard, if CODI is doing exactly what it is supposed to do, can you please clarify-me in terms of view management, what exactly are the responsabilities of CODI? - Is codi's main responsability destroying CDI beans qualified with the View Scope qualifier? Or does it go beyond that to also deal with JSF state managament? - How do you deal with the possibility that CODI can potentially support an infinite number of views per user session, and specific JSF implementation only supports three? Leaking to view destruction of view 1 as soon CODI opens the view 4 for user session? This is beyond the scope of CODI? Finally, may I then ask why the EditableWindowContextManager.close(WindowContext) seems to take a more active role in the distruction of a Window by clearing out the LRU map you use, while the WindowContext.close() seems to - i guess - only wipeout the View Scoped beans? How to projects typically end up using CODI? Say a user does not use Iframes, and accesses every page in the context of a windowId. Now the user opens a new tab which begets its own new window Id. We have now two separate WindowContexts. If the use now decides to close the new tab, those session objects and window scoped SCI beans will continue alive until the end of the user session? Gerhard, concerning your comment about replacing the views in the client side as opposed of doing ti through typical JSF view navigation. You are correct that this does indeed lead to the creation of many more views that a typical use case. By default, when we are navigation from one .xhtml to a new one, we destroy one window and crate a new one. But this also provides an easy manner of cleaning up after beans used in that view. When you go from one page to antoher, you cleanup after all the beans that were needed before and get new fresh beans for the new view. If you do not kill windows frequently and create new ones to replace the old ones, your window scoped beans end-up being like session scoped beans (e.g. if we imagine that we do not open a second tab - otherwise there is a real different between window scoper and session scoped beans). Many thanks. was (Author: ngdem): Hi, and once again, I thank you both for the great input. Concerning Majorra implementation: Leo, Majorra in JSF 2.1 using server side state saving, looks at an incoming request, namely at the automatically injected input field: javax.faces.ViewState request parameter, and checks weather it is "stateless" for transient views, or if it is somelhinkg like "logicalMapKey:actualMapKey". If the thing has an actual value in there, JSF will try to recover that view, accessing a special HTTP session property where all the state is serialized. What happens is that regardless of the logical limit of CODI (64 views), by default the JSF standard will allow you only to have up to 15 records in that logical map. After that the LRU put method just knocks out the least recently entry on that map. This is a potential-critical point for issues. The gap between the size of both buffers. But I see from Gerhard's post that CODI has to abstract itself from whichever way the underlying JSF implementation is deciding to manage the view state. But Leo and Gerhard, if CODI is doing exactly what it is supposed to do, can you please clarify-me in terms of view management, what exactly are the responsabilities of CODI? - Is codi's main responsability destroying CDI beans qualified with the View Scope qualifier? Or does it go beyond that to also deal with JSF state managament? - How do you deal with the possibility that CODI c
[jira] [Comment Edited] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page
[ https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140257#comment-14140257 ] Nuno G. de M edited comment on EXTCDI-316 at 9/19/14 10:00 AM: --- Hi, and once again, I thank you both for the great input. Concerning Majorra implementation: Leo, Majorra in JSF 2.1 using server side state saving, looks at an incoming request, namely at the automatically injected input field: javax.faces.ViewState request parameter, and checks weather it is "stateless" for transient views, or if it is somelhinkg like "logicalMapKey:actualMapKey". If the thing has an actual value in there, JSF will try to recover that view, accessing a special HTTP session property where all the state is serialized. What happens is that regardless of the logical limit of CODI (64 views), by default the JSF standard will allow you only to have up to 15 records in that logical map. After that the LRU put method just knocks out the least recently entry on that map. This is a potential-critical point for issues. The gap between the size of both buffers. But I see from Gerhard's post that CODI has to abstract itself from whichever way the underlying JSF implementation is deciding to manage the view state. But Leo and Gerhard, if CODI is doing exactly what it is supposed to do, can you please clarify-me in terms of view management, what exactly are the responsabilities of CODI? - Is codi's main responsability destroying CDI beans qualified with the View Scope qualifier? Or does it go beyond that to also deal with JSF state managament? - How do you deal with the possibility that CODI can potentially support an infinite number of views per user session, and specific JSF implementation only supports three? Leaking to view destruction of view 1 as soon CODI opens the view 4 for user session? This is beyond the scope of CODI? Finally, may I then ask why the EditableWindowContextManager.close(WindowContext) seems to take a more active role in the distruction of a Window by clearing out the LRU map you use, while the WindowContext.close() seems to - i guess - only wipeout the View Scoped beans? How to projects typically end up using CODI? Say a user does not use Iframes, and accesses every page in the context of a windowId. Now the user opens a new tab which begets its own new window Id. We have now two separate WindowContexts. If the use now decides to close the new tab, those session objects and window scoped SCI beans will continue alive until the end of the user session? Gerhard, concerning your comment about replacing the views in the client side as opposed of doing ti through typical JSF view navigation. You are correct that this does indeed lead to the creation of many more views that a typical use case. By default, when we are navigation from one .xhtml to a new one, we destroy one window and crate a new one. But this also provides an easy manner of cleaning up after beans used that were present in that old view/xhtml. When you go from one page to antoher, you cleanup after all those old beans that were instantiated to support the .xhtml you swapped out. The new page gets fresh independent state, and user sessions are lighter because of this constant destruction of old views. If you do not kill windows frequently, and keep that one single window forever alive, unless you use more than one tab, your window scoped beans end-up being like session scoped beans (e.g. they will last until the end of the session). Many thanks. was (Author: ngdem): Hi, and once again, I thank you both for the great input. Concerning Majorra implementation: Leo, Majorra in JSF 2.1 using server side state saving, looks at an incoming request, namely at the automatically injected input field: javax.faces.ViewState request parameter, and checks weather it is "stateless" for transient views, or if it is somelhinkg like "logicalMapKey:actualMapKey". If the thing has an actual value in there, JSF will try to recover that view, accessing a special HTTP session property where all the state is serialized. What happens is that regardless of the logical limit of CODI (64 views), by default the JSF standard will allow you only to have up to 15 records in that logical map. After that the LRU put method just knocks out the least recently entry on that map. This is a potential-critical point for issues. The gap between the size of both buffers. But I see from Gerhard's post that CODI has to abstract itself from whichever way the underlying JSF implementation is deciding to manage the view state. But Leo and Gerhard, if CODI is doing exactly what it is supposed to do, can you please clarify-me in terms of view management, what exactly are the responsabilities of CODI? - Is codi's main responsability destroying CDI beans qualified with the View Scope qualifier? Or does it g
[jira] [Comment Edited] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page
[ https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140257#comment-14140257 ] Nuno G. de M edited comment on EXTCDI-316 at 9/19/14 10:21 AM: --- Hi, and once again, I thank you both for the great input. Concerning Majorra implementation: Leo, Majorra in JSF 2.1 using server side state saving, looks at an incoming request, namely at the automatically injected input field: javax.faces.ViewState request parameter, and checks weather it is "stateless" for transient views, or if it is somelhinkg like "logicalMapKey:actualMapKey". If the thing has an actual value in there, JSF will try to recover that view, accessing a special HTTP session property where all the state is serialized. What happens is that regardless of the logical limit of CODI (64 views), by default the JSF standard will allow you only to have up to 15 records in that logical map. After that the LRU put method just knocks out the least recently entry on that map. This is a potential-critical point for issues. The gap between the size of both buffers. But I see from Gerhard's post that CODI has to abstract itself from whichever way the underlying JSF implementation is deciding to manage the view state. But Leo and Gerhard, if CODI is doing exactly what it is supposed to do, can you please clarify-me in terms of view management, what exactly are the responsabilities of CODI? - Is codi's main responsability destroying CDI beans qualified with the View Scope qualifier? Or does it go beyond that to also deal with JSF state managament? - How do you deal with the possibility that CODI can potentially support an infinite number of views per user session, and specific JSF implementation only supports three? Leaking to view destruction of view 1 as soon CODI opens the view 4 for user session? This is beyond the scope of CODI? Finally, may I then ask why the EditableWindowContextManager.close(WindowContext) seems to take a more active role in the distruction of a Window by clearing out the LRU map you use, while the WindowContext.close() seems to - i guess - only wipeout the View Scoped beans? How to projects typically end up using CODI? Say a user does not use Iframes, and accesses every page in the context of a windowId. Now the user opens a new tab which begets its own new window Id. We have now two separate WindowContexts. If the use now decides to close the new tab, those session objects and window scoped SCI beans will continue alive until the end of the user session? Gerhard, concerning your comment about replacing the views in the client side as opposed of doing ti through typical JSF view navigation. You are correct that this does indeed lead to the creation of many more views that a typical use case. By default, when we are navigation from one .xhtml to a new one, we destroy one window and crate a new one. But this also provides an easy manner of cleaning up after beans used that were present in that old view/xhtml. When you go from one page to antoher, you cleanup after all those old beans that were instantiated to support the .xhtml you swapped out. The new page gets fresh independent state, and user sessions are lighter because of this constant destruction of old views. If you do not kill windows frequently, and keep that one single window forever alive, unless you use more than one tab, your window scoped beans end-up being like session scoped beans (e.g. they will last until the end of the session). Do you belive the following is possible with CODI: (a) Each Ifram has its own windowId (as present) (b) Iframe navigation is done he standard JSF way, keepign the view state and windowID that previously occupied the iframe (e.g. no new CODI window context creation, no new JSF view state entry generation) (c) As part of the navigation onto a new view - convesation scoped beans that were active before the POST get wipedout and new convesation scoped beans are created to fill in the new view? That means - demoting very Bean currently annotated with WindowScoped to ConversationScoped, and having an adequate spot in the postback to the server that leads to an .xhtml navigation to do this bean cleaning? If so, where exactly it the spot to place such a WindowContext.destroyAllConverstationScopedBeans() of old xhtml? Many thanks. was (Author: ngdem): Hi, and once again, I thank you both for the great input. Concerning Majorra implementation: Leo, Majorra in JSF 2.1 using server side state saving, looks at an incoming request, namely at the automatically injected input field: javax.faces.ViewState request parameter, and checks weather it is "stateless" for transient views, or if it is somelhinkg like "logicalMapKey:actualMapKey". If the thing has an actual value in there, JSF will try to recover that view, accessing a special HTTP sessio
[jira] [Commented] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page
[ https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140330#comment-14140330 ] Gerhard Petracek commented on EXTCDI-316: - please don't mix the view-scope (@ViewScoped) and the codi scopes (per window): @WindowScoped, @ConversationScoped, @ViewAccessScoped. the bridge for the view-scope just transforms a jsf-bean to a cdi bean and via a PreDestroyViewMapEvent listener codi gets notified by the jsf-implementation to destroy the corresponding cdi-beans. however, afair esp. mojarra used to have issues with those events in the beginning - so i wouldn't use it before ee7 (which supports that out-of-the-box and has to handle it internally). #closeWindowContext is just a helper to do a full cleanup including the component-tree. in deltaspike we don't have that any longer to keep it simpler. @timeout: yes and no - if the user-session gets closed (due to a timeout or manually) all those codi-scoped beans get dropped as well. however, there is e.g. also a window-timeout which is shorter than the session-timeout (usually - see WindowContextConfig#getWindowContextTimeoutInMinutes). in deltaspike we dropped that as well - there you only have the session-timeout which destroys the windows as well. yes @WindowScoped (and WindowContext) can get to a "session per browser-tab" easily. >that< is the use-case for it/them. therefore you have @ConversationScoped and @ViewAccessScoped which are more fine-grained. using @WindowScoped isn't that usual compared to the other two scopes (which are also stored in the current window and therefore support the window-id implicitly - see e.g. https://cwiki.apache.org/confluence/display/EXTCDI/JSF+Usage#JSFUsage-Scopes). @WindowScoped helps e.g. if you like to store the nav.history per window or the menu-state independent of the component-tree. WindowContext is just the storage per window you (as user) usually don't need to touch manually. (you just need it to handle your use-case with iframes.) you could introduce a new url-parameter and add it on the client-side once you replace the iframe-content there. something like oldWindowIdToDrop -> just destroy the window on the server-side via a phase-listener (or in your own WindowHandler) once you detect your custom url-parameter. > Close window context view leakge - JSF 2.1 Multiple Iframes per page > > > Key: EXTCDI-316 > URL: https://issues.apache.org/jira/browse/EXTCDI-316 > Project: MyFaces CODI > Issue Type: Bug > Components: Core >Affects Versions: 1.0.3 > Environment: Oracle GlassFish Server 3.1.2.5 (build 2), jdk1.6.0_45 >Reporter: Nuno G. de M > Original Estimate: 72h > Remaining Estimate: 72h > > Hi, and thank you for your support. > First, I would just like to stat that I am unsure if the "issue" detected in > our application is a real issue within CODI, or if it is we that are misusing > the framework. Therefore, I would be happy to get your input on the issue I > am about to detail. > ISSUE SUMMARY: > - we have a ui architecture comprised by several Iframes within a main page, > where each iframe has its own CODI window context. After several clicks > replacing the content that of a targetIfram by new content, we were having > CODI view context leakage as well as JSF view state leakage. > ISSUE DETAILS: > For historical as well performance reasons reasons, we have a UI that is > composed into several IFrames within a parent portal iframe. This decomposing > of the view into sub-views means the JSF context to serialize-deserialize per > iframe/.xhtml present in the UI is smaller. As opposed to a single big-ui > view state. > An overview of the core iframes invovled would be: > (1) window.top - Contains the Header and a left-side navigation menu > (2) window.top.contentIfram - Iframe Contains your typical page conent > (.xhtml) > (3) window.top.footer - iframe containing a dynamic footer (its own .xhtml) > (4) wintow.top.applet - Iframe that includes an applet > (5) window.top.special - an auxiliary .xhtml that complements the applet data > (6) window.top.clean - iframe that contains an .xhtml to do CODI window > context and JSF sever state cleanup (created to deal with the issue being > explained here) > The BUG in view navigation is the following: > Each time the user interacts with the UI, e.g by clicing on an menu command > button, or on a applet view element, prompting for a new .xhtml view to be > loaded and replace the old .xhtml loaded on a target iframe we leak both a > JSF and CODI window context. > Our steps are the following: > (1) we change the src of the iframe to point to the new view to be loaded > e.g iframe.src = 'urlTonewPageToBeLoaded.xhtml?requestViewParameters' > In this requ
Re: [VOTE] Release of MyFaces Core 2.2.5
Here is my +1 Regards Bernd On Thu, Sep 18, 2014 at 6:09 PM, Martin Marinschek wrote: > +1 > > Regards, > > Martin > > Am 18.09.2014 13:10 schrieb "Werner Punz" : > >> +1 >> >> Am 16.09.14 20:53, schrieb Leonardo Uribe: >>> >>> +1 >>> >>> 2014-09-16 13:53 GMT-05:00 Leonardo Uribe : Hi, I was running the needed tasks to get the 2.2.5 release of Apache MyFaces core out. The artifacts passed the TCK test of Feb 2013 (jsftck-2.2_26-Feb-2013.zip). Please note that this vote concerns all of the following parts: 1. Maven artifact group "org.apache.myfaces.shared" v4.2.4 [1] 2. Maven artifact group "org.apache.myfaces.core" v2.2.5 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the "2.2.5" artifacts and vote! Please note: This vote is "majority approval" with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-1031/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces225binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&version=12327190 >>> >>> >> >> >
[jira] [Commented] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page
[
https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140797#comment-14140797
]
Nuno G. de M commented on EXTCDI-316:
-
Hi Gerhard, thanks a lot for the feedback.
Concerning the viewScoped, I made a mistake, because I was thinking of the CODI
scope "@WindowScoped" instead.
@windoIdToToDrop
That is actually what we do, but it is more tricky than that actually.
Before switching the iframe from the client Side, we ajax the server telling it
to know about the windowId about to be swapped out.
Finally, only on the onloadEvent of the new iframe can you actually really kill
the "windowIdToDrop".
The reason for this is that while you are loading a new window onto this
iframe, if you use "comet-like" mechanism, the page can still be polling
iformation from the server - and were youto wipeout the state until the view is
replaced, you would a view expired exception.
So far the safest approach, would be, if it were possible, to keep the
windowId/context of a given iframe constant throughout time as well as the
corresponding JSF server side state key.
That means using standard JSF navigation to swap the view of a given iframe.
But this also implies that in order to do this, all the beans created within
the scope of this windo iframe would have to be thrown away and replaced by the
new beans for the view.
This would be the ideal thing.
> Close window context view leakge - JSF 2.1 Multiple Iframes per page
>
>
> Key: EXTCDI-316
> URL: https://issues.apache.org/jira/browse/EXTCDI-316
> Project: MyFaces CODI
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.3
> Environment: Oracle GlassFish Server 3.1.2.5 (build 2), jdk1.6.0_45
>Reporter: Nuno G. de M
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> Hi, and thank you for your support.
> First, I would just like to stat that I am unsure if the "issue" detected in
> our application is a real issue within CODI, or if it is we that are misusing
> the framework. Therefore, I would be happy to get your input on the issue I
> am about to detail.
> ISSUE SUMMARY:
> - we have a ui architecture comprised by several Iframes within a main page,
> where each iframe has its own CODI window context. After several clicks
> replacing the content that of a targetIfram by new content, we were having
> CODI view context leakage as well as JSF view state leakage.
> ISSUE DETAILS:
> For historical as well performance reasons reasons, we have a UI that is
> composed into several IFrames within a parent portal iframe. This decomposing
> of the view into sub-views means the JSF context to serialize-deserialize per
> iframe/.xhtml present in the UI is smaller. As opposed to a single big-ui
> view state.
> An overview of the core iframes invovled would be:
> (1) window.top - Contains the Header and a left-side navigation menu
> (2) window.top.contentIfram - Iframe Contains your typical page conent
> (.xhtml)
> (3) window.top.footer - iframe containing a dynamic footer (its own .xhtml)
> (4) wintow.top.applet - Iframe that includes an applet
> (5) window.top.special - an auxiliary .xhtml that complements the applet data
> (6) window.top.clean - iframe that contains an .xhtml to do CODI window
> context and JSF sever state cleanup (created to deal with the issue being
> explained here)
> The BUG in view navigation is the following:
> Each time the user interacts with the UI, e.g by clicing on an menu command
> button, or on a applet view element, prompting for a new .xhtml view to be
> loaded and replace the old .xhtml loaded on a target iframe we leak both a
> JSF and CODI window context.
> Our steps are the following:
> (1) we change the src of the iframe to point to the new view to be loaded
> e.g iframe.src = 'urlTonewPageToBeLoaded.xhtml?requestViewParameters'
> In this request we do not inclode the old windowId of the iframe being
> replaced. Meaning codi will have to create a new view ID for this new page
> load.
> (2) We also trigger an ajax request to server to have the old codi window
> context being closed.
> Intially here did:
> (2.1)WindowContext wContext =
> windowContextManager.getWindowContext('windowIdToClose);
> wContext.close()
> It turns out that as we did these two steps we had two leakages.
> After about 64 clicks on the applet, if we interatcted with views that the
> applet had been loading we would have no issues. If we clicked on some of
> the older views that had been loaded after the login and not interacted with
> since then (e.g. the footer) we would have a view timeout exception.
> This happened because with each new iframe.src='newView', CODI was not
> cleaning up its window context map, namely the following line:
> this.wi
[jira] [Comment Edited] (EXTCDI-316) Close window context view leakge - JSF 2.1 Multiple Iframes per page
[ https://issues.apache.org/jira/browse/EXTCDI-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140797#comment-14140797 ] Nuno G. de M edited comment on EXTCDI-316 at 9/19/14 4:25 PM: -- Hi Gerhard, thanks a lot for the feedback. Concerning the viewScoped, I made a mistake, because I was thinking of the CODI scope "@WindowScoped" instead. @windoIdToToDrop That is actually what we do, but it is more tricky than that actually. Before switching the iframe from the client Side, we ajax the server telling it to know about the windowId about to be swapped out. Finally, only on the onloadEvent of the new iframe can you actually really kill the "windowIdToDrop". The reason for this is that while you are loading a new window onto this iframe, if you use "comet-like" mechanism, the page can still be polling iformation from the server - and were youto wipeout the state until the view is replaced, you would a view expired exception. Your feedback was very helpful, I think i know how to proceed to make the UI more stable Thanks. was (Author: ngdem): Hi Gerhard, thanks a lot for the feedback. Concerning the viewScoped, I made a mistake, because I was thinking of the CODI scope "@WindowScoped" instead. @windoIdToToDrop That is actually what we do, but it is more tricky than that actually. Before switching the iframe from the client Side, we ajax the server telling it to know about the windowId about to be swapped out. Finally, only on the onloadEvent of the new iframe can you actually really kill the "windowIdToDrop". The reason for this is that while you are loading a new window onto this iframe, if you use "comet-like" mechanism, the page can still be polling iformation from the server - and were youto wipeout the state until the view is replaced, you would a view expired exception. So far the safest approach, would be, if it were possible, to keep the windowId/context of a given iframe constant throughout time as well as the corresponding JSF server side state key. That means using standard JSF navigation to swap the view of a given iframe. But this also implies that in order to do this, all the beans created within the scope of this windo iframe would have to be thrown away and replaced by the new beans for the view. This would be the ideal thing. > Close window context view leakge - JSF 2.1 Multiple Iframes per page > > > Key: EXTCDI-316 > URL: https://issues.apache.org/jira/browse/EXTCDI-316 > Project: MyFaces CODI > Issue Type: Bug > Components: Core >Affects Versions: 1.0.3 > Environment: Oracle GlassFish Server 3.1.2.5 (build 2), jdk1.6.0_45 >Reporter: Nuno G. de M > Original Estimate: 72h > Remaining Estimate: 72h > > Hi, and thank you for your support. > First, I would just like to stat that I am unsure if the "issue" detected in > our application is a real issue within CODI, or if it is we that are misusing > the framework. Therefore, I would be happy to get your input on the issue I > am about to detail. > ISSUE SUMMARY: > - we have a ui architecture comprised by several Iframes within a main page, > where each iframe has its own CODI window context. After several clicks > replacing the content that of a targetIfram by new content, we were having > CODI view context leakage as well as JSF view state leakage. > ISSUE DETAILS: > For historical as well performance reasons reasons, we have a UI that is > composed into several IFrames within a parent portal iframe. This decomposing > of the view into sub-views means the JSF context to serialize-deserialize per > iframe/.xhtml present in the UI is smaller. As opposed to a single big-ui > view state. > An overview of the core iframes invovled would be: > (1) window.top - Contains the Header and a left-side navigation menu > (2) window.top.contentIfram - Iframe Contains your typical page conent > (.xhtml) > (3) window.top.footer - iframe containing a dynamic footer (its own .xhtml) > (4) wintow.top.applet - Iframe that includes an applet > (5) window.top.special - an auxiliary .xhtml that complements the applet data > (6) window.top.clean - iframe that contains an .xhtml to do CODI window > context and JSF sever state cleanup (created to deal with the issue being > explained here) > The BUG in view navigation is the following: > Each time the user interacts with the UI, e.g by clicing on an menu command > button, or on a applet view element, prompting for a new .xhtml view to be > loaded and replace the old .xhtml loaded on a target iframe we leak both a > JSF and CODI window context. > Our steps are the following: > (1) we change the src of the iframe to point to the new view to be loaded > e.g iframe.src = 'urlTonewPageToBeLoaded.xhtml?requestVie
Re: [VOTE] Release of MyFaces Core 2.2.5
+1 LieGrue, strub > On Friday, 19 September 2014, 17:46, Bernd Bohmann > wrote: > > Here is my > > +1 > > Regards > > Bernd > > > On Thu, Sep 18, 2014 at 6:09 PM, Martin Marinschek > wrote: >> +1 >> >> Regards, >> >> Martin >> >> Am 18.09.2014 13:10 schrieb "Werner Punz" > : >> >>> +1 >>> >>> Am 16.09.14 20:53, schrieb Leonardo Uribe: +1 2014-09-16 13:53 GMT-05:00 Leonardo Uribe > : > > Hi, > > I was running the needed tasks to get the 2.2.5 release of > Apache > MyFaces core out. > > The artifacts passed the TCK test of Feb 2013 > (jsftck-2.2_26-Feb-2013.zip). > > Please note that this vote concerns all of the following parts: >1. Maven artifact group "org.apache.myfaces.shared" > v4.2.4 [1] >2. Maven artifact group "org.apache.myfaces.core" > v2.2.5 [1] > > The artifacts were deployed on nexus repo [1] and to my private > Apache account [3] for binary and source packages. > > The release notes could be found at [4]. > > Also the clirr test does not show binary incompatibilities with > myfaces-api. > > Please take a look at the "2.2.5" artifacts and vote! > > Please note: This vote is "majority approval" with a > minimum of three > +1 votes (see [3]). > > > [ ] +1 for community members who have reviewed the bits > [ ] +0 > [ ] -1 for fatal flaws that should cause these bits not to be > released, >and why.. > > > Thanks, > Leonardo Uribe > > [1] > > https://repository.apache.org/content/repositories/orgapachemyfaces-1031/org/apache/myfaces/ > [2] http://www.apache.org/foundation/voting.html#ReleaseVotes > [3] http://people.apache.org/~lu4242/myfaces225binsrc > [4] > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&version=12327190 >>> >>> >> >
