[
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)
