You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Igor Vaynberg (JIRA)" <ji...@apache.org> on 2010/08/07 21:04:00 UTC
[jira] Updated: (WICKET-1010) Contract of Session.attach() and
Session.detach()
[ https://issues.apache.org/jira/browse/WICKET-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Igor Vaynberg updated WICKET-1010:
----------------------------------
Fix Version/s: 1.5-M2
(was: 1.5-M1)
> Contract of Session.attach() and Session.detach()
> -------------------------------------------------
>
> Key: WICKET-1010
> URL: https://issues.apache.org/jira/browse/WICKET-1010
> Project: Wicket
> Issue Type: Bug
> Reporter: Martin Funk
> Fix For: 1.5-M2
>
>
> What is the contract of Session.attach() and Session.detach() ?
> Especially, is it intended that after a call to attach() that there will
> be at least one call to detach() before the request goes back to the client?
> If that's the case, then there might be a bug in Session and I propose
> the following patch on org.apache.wicket.Session
> Index: .
> ===================================================================
> --- . (revision 579354)
> +++ . (working copy)
> @@ -305,6 +305,11 @@
> */
> public static void unset()
> {
> + Session session = (Session)current.get();
> + if (session != null)
> + {
> + session.detach();
> + }
> current.set(null);
> }
> In my current project well fell over this looking at:
> WicketFilter.getLastModified(final HttpServletRequest servletRequest)
> where cachable resources lead over Session.findOrCreate to Session.set(Session) to Session.attach()
> but the Session.unset() doesn't lead to a Session.detach()
> Martin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.