[ 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 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.windowContextMap.remove(editableWindowContext.getId()); > is not executed during a WindowContext.close(). > So despite our class to close the window context, the map would continue to > hold the view just closed. After 64 clicks the view uffer of CODI would be > totally populated, and each new click was destroying the one of the least > recently used views. This could be the main menu, this could be the page > content or this could be the footer. > To address this issue, we had to start injecting the > EditableWindowContextManager, and use its close API. > So the procedure for closing a CODI window context avoiding CODI view leakge > turned into a : > Map<String, EditableWindowContext> existingContextIds = > getExistingContextIds(); > windowContextManager.closeWindowContext(windowIdOfContextToClose); > Finally, there was still one last view leakge to address. > Even when we use the > windowContextManager.closeWindowContext(windowIdOfContextToClose), the JSF > view state associate to this view still exists in the JSF view map. > JSF-core (e.g majorra) seems to have a limit of 15 views within this LRU > logical map. > So once we stopped leaking views in CODI, we still had to tackle the leakage > in JSF. Meaning, when we close a CODI window context, we need to the > javax.views.state string to access the JSF map of logical views and remove > them. > Object sessionObj = externalContext.getSession(false); > synchronized (sessionObj) { > Map logicalMap = (Map) externalContext.getSessionMap().get(LOGICAL_VIEW_MAP); > Map actualMap = (Map) logicalMap.get(idInLogicalMap); > actualMap.clear(); > // remove the leaked view from the LRU map of logical > views > logicalMap.remove(idInLogicalMap); > } > ------ > Naturally, an application should normally not have to dig deep into framework > code. One of the two is for sure true: > - either we are misusing CODI to manage our views > - or CODI has an issue > Thanks in advance for any input on this issue. -- This message was sent by Atlassian JIRA (v6.3.4#6332)