[ http://issues.apache.org/jira/browse/TOMAHAWK-672?page=all ]
Mario Ivankovits resolved TOMAHAWK-672.
---------------------------------------
Fix Version/s: 1.1.5-SNAPSHOT
Resolution: Fixed
Hi!
I added a policy configuration to customize the data being saved between
redirects
New context configuration parameters:
org.apache.myfaces.redirectTracker.MAX_REDIRECTS - Default: 20
Number of redirects to track - required to allow the back-button to work.
org.apache.myfaces.redirectTracker.POLICY - Default:
org.apache.myfaces.custom.redirectTracker.policy.NoopRedirectTrackPolicy
The policy used to describe which data to save between requests. This can be
any FQN to a class implementing the RedirectTrackerPolicy.
Current implementations are:
* org.apache.myfaces.custom.redirectTracker.policy.FullRedirectTrackPolicy
Captures request beans, local and messages
* org.apache.myfaces.custom.redirectTracker.policy.MessagesRedirectTrackPolicy
Captures FacesMessages only
* org.apache.myfaces.custom.redirectTracker.policy.NoopRedirectTrackPolicy
Captures nothing (the default for JSF backward compatiblity)
> RedirectTrackerManager behavior must be disabled by default
> -----------------------------------------------------------
>
> Key: TOMAHAWK-672
> URL: http://issues.apache.org/jira/browse/TOMAHAWK-672
> Project: MyFaces Tomahawk
> Issue Type: Bug
> Components: New Component
> Affects Versions: 1.1.5-SNAPSHOT
> Reporter: David Delbecq
> Assigned To: Mario Ivankovits
> Fix For: 1.1.5-SNAPSHOT
>
>
> The redirectTrackerManager store datas it find in the request scope of
> current request to restore them after a redirect. However, it does it
> automatically, leading to problems at 2 levels
> 1) It has a default size of 20 redirect, meaning if you create temporary
> objects of about 500k in your request (like an xml file to render as an
> example) you can end up with 10M / user session, when you have about 30
> active users at the same time (not so improbable if you have session timeout
> of about 1h), this reach the level of 300M of datas in memory used just by
> the TrackerManager! This is too expensive
> 2) When you design your application, you assume that what is request scope
> stays in request scope. There is no recommendation i know of that suggest you
> store only serializable objects in request scope. On the other hand,
> Everything in Session scope should be serializable. By transfering datas from
> request scope to session scope without warning (just including the
> sandbox.jar is enough to activate this behaviour), RedirectTrackerManager is
> breaking the specs, storing unserializable objects in session, preventing
> serialization of the session.
> For all those reason, you should:
> 1) make the RedirectTrackerManager an optional component, not an automic
> behaviour as soon as you include the sandbox jar. This would pervent the
> surprise of seeing the session size explode, and take into account clustered
> environment (in which, for already mentionned serialization reason, the
> redirect tracker is by design broken and should not be used)
> 2) Have the redirectEntryMap field in RedirectTrackerManager marked
> transient, to prevent serialization attempts of request scope datas.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
