[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=14138666#comment-14138666
]
Gerhard Petracek commented on EXTCDI-316:
-
no - that's the reason i didn't mention it (mojarra vs. myfaces-core).
codi is compatible with both and we know users with huge codi/jsf (with
mojarra) based projects.
leo just mentioned that myfaces-core is smarter when it comes to state-saving
and the chance is higher that you won't see (some of) the issues you saw with
mojarra caused by the usage of iframes.
e.g. once the fallback to WindowContextIdHolderComponent is used to resolve the
window-id, the proper handling depends on the quality of the state-saving
algorithm (provided by the jsf implementation).
once you call #close for the correct window manually, you don't see a leak >in
codi<.
however, since there is no jsf-api for it, codi can't trigger a cleanup of the
view-state.
jsf 2.2 introduced the window-concept (based on apis introduced by codi and
similar frameworks).
however, even with jsf 2.2, the jsf implementation is responsible for doing a
cleanup of the state internally (there is no explicit api for it).
the benefit for users is that the jsf implementation is aware of windows (as a
concept) and >can< do improvements (more easily) for handling the state in a
better way (but there is no specified rule for it).
@iframes:
it >sounds< like the major issue in your case is that you replace the content
of the iframe on the client-side.
a lot really depends on details of your implementation and maybe even on other
details like the used browser (you wouldn't belief how hard it is to support
something simple like the proper handling after "open in new tab" across the
major browsers).
> 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 wo
[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=14138681#comment-14138681
]
Leonardo Uribe commented on EXTCDI-316:
---
CODI is doing right what it is supposed to do. There is no doubt about that.
I ignore the details behind Mojarra, but I suppose an LRU map does not solve
the problem fully. The best you can find from JSF perspective is inside MyFaces
Core. In that part we have a precedence algorithm that keep track the views and
its ordering and it aims to purge the views with an algorithm specifically
designed to deal with multiple windows.
In MyFaces Core 2.2 we have a more advanced algorithm, that is able to destroy
JSF 2.2 view scope beans as soon as the view is discarded from the session, but
for your case that's not necessary, the improved algorithm in MyFaces Core 2.1
will do it fine.
> 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
[jira] [Created] (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
Anshu Jain created TRINIDAD-2509: Summary: 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 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)
Re: [VOTE] Release of MyFaces Core 2.2.5
+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] (TOBAGO-939) RenderedPartially support for sheet and tabGroup
[ https://issues.apache.org/jira/browse/TOBAGO-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14138920#comment-14138920 ] Hudson commented on TOBAGO-939: --- SUCCESS: Integrated in tobago-trunk #1261 (See [https://builds.apache.org/job/tobago-trunk/1261/]) TOBAGO-939 - RenderedPartially support for sheet and tabGroup (lofwyr: http://svn.apache.org/viewvc/?view=rev&rev=1625968) * /myfaces/tobago/trunk/tobago-theme/tobago-theme-standard/src/main/java/org/apache/myfaces/tobago/renderkit/html/standard/standard/tag/SheetRenderer.java > RenderedPartially support for sheet and tabGroup > > > Key: TOBAGO-939 > URL: https://issues.apache.org/jira/browse/TOBAGO-939 > Project: MyFaces Tobago > Issue Type: Improvement >Affects Versions: 1.5.0-alpha-1 >Reporter: Bernd Bohmann >Assignee: Udo Schnurpfeil > Fix For: 2.0.3 > > > It would be nice if can define the new rendered region. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TOBAGO-939) RenderedPartially support for sheet and tabGroup
[ https://issues.apache.org/jira/browse/TOBAGO-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-939. Resolution: Fixed Fix Version/s: 3.0.0 3.0.0-alpha-1 > RenderedPartially support for sheet and tabGroup > > > Key: TOBAGO-939 > URL: https://issues.apache.org/jira/browse/TOBAGO-939 > Project: MyFaces Tobago > Issue Type: Improvement >Affects Versions: 1.5.0-alpha-1 >Reporter: Bernd Bohmann >Assignee: Udo Schnurpfeil > Fix For: 2.0.3, 3.0.0-alpha-1, 3.0.0 > > > It would be nice if can define the new rendered region. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TOBAGO-939) RenderedPartially support for sheet and tabGroup
[ https://issues.apache.org/jira/browse/TOBAGO-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14138995#comment-14138995 ] Hudson commented on TOBAGO-939: --- SUCCESS: Integrated in tobago-trunk #1262 (See [https://builds.apache.org/job/tobago-trunk/1262/]) TOBAGO-939 - RenderedPartially support for sheet and tabGroup - clean up (lofwyr: http://svn.apache.org/viewvc/?view=rev&rev=1625972) * /myfaces/tobago/trunk/tobago-theme/tobago-theme-standard/src/main/resources/org/apache/myfaces/tobago/renderkit/html/standard/standard/script/tobago-sheet.js > RenderedPartially support for sheet and tabGroup > > > Key: TOBAGO-939 > URL: https://issues.apache.org/jira/browse/TOBAGO-939 > Project: MyFaces Tobago > Issue Type: Improvement >Affects Versions: 1.5.0-alpha-1 >Reporter: Bernd Bohmann >Assignee: Udo Schnurpfeil > Fix For: 2.0.3, 3.0.0-alpha-1, 3.0.0 > > > It would be nice if can define the new rendered region. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release of MyFaces Core 2.2.5
+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] (TRINIDAD-2504) DateFormat.js incorrectly implements 'D' (day of year) parsing
[ https://issues.apache.org/jira/browse/TRINIDAD-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14140025#comment-14140025 ] Yee-Wah Lee commented on TRINIDAD-2504: --- Further fixes have been made in Trinidad-2509, consumers of this fix should also include the changes there. > DateFormat.js incorrectly implements 'D' (day of year) parsing > -- > > Key: TRINIDAD-2504 > URL: https://issues.apache.org/jira/browse/TRINIDAD-2504 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 2.1.0-core >Reporter: Yee-Wah Lee >Priority: Minor > Fix For: 2.1.1-core > > Attachments: trin_2504_DateFormatDayOfYear.diff > > > 1. Create an inputDate with a converter that uses 'D' (day of year) pattern > and no initial value > e.g. > > > > 2. Run the demo and pick the 1st of January (any year) > 3. The input shows 355, the correct value should be 1. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
