[
https://issues.apache.org/jira/browse/WICKET-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timo Rantalaiho updated WICKET-1010:
------------------------------------
Fix Version/s: (was: 1.4-M4)
1.5-M1
To maintain more 1.3 compatibility it might be better to only fix this in 1.5.
But if you think that it's too dangerous to leave it in 1.4, let's move this
issue back to 1.4. I don't think the issue is so serious though, as it doesn't
appear on the mailing lists?
> 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-M1
>
>
> 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.
