Yeah, that's it. Sorry if I failed to convey the why's very well. I was really exhausted (12 hour day, little sleep) when I tried to write that WIKI explanation. So here's more:
The problem we have, that I think others will eventually run into, is that you may want to sign a user in during session construction, most likely under testing, but there could be other reasons. Until this change was made, it was actually impossible to do this because you could not set a cookie in your session constructor at all (testing or not) because the request cycle (which holds the response for the current thread to set a cookie on) was being constructed after session construction using a factory contained in the session (which is a very bad location for this, in hindsight). We've disliked this organization of things for a long time, but it was this use case that finally pushed us to make this change. It was certainly possible to hack around this by creating a custom request cycle factory (which would mean several times as many lines and a very non-intuitive solution for others who run into this) and sweeping this all under the rug with business-as-usual, but the benefits of doing this right were finally too hard to ignore. We actually shrank the amount of code considerably with this change. The result is better, faster, smaller and less confusing for both users and developers of Wicket. Eelco Hillenius wrote: > > http://cwiki.apache.org/WICKET/migrate-13.html#Migrate-1.3-RequestCycle%252CIRequestCycleFactory%252CSession%252CIPageMapandPageMapchanges >> > helps. >> >> this says what, but not the why. > > Ok, I thought it was obvious from just looking at the changes, but here we > go. > > * We got rid of getDefaultRequestCycleFactory and replaced it by > getRequestCycleFactory in Application, and we don't create the request > cycle through the session anymore. That's what but if you pull out > your API elegance tentacles, it's the why as well. > * We only create a session instance when we really need to (it's > created lazily). Possibly a slight optimization. The creation and > registering of the session is all in the right place now. Not > scattered througout wicket filter and application, but just in the > session itself. > * The request cycle is now available in the Session's constructor. I > believe this was what Jonathan needed for better testing support, but > I'm not sure. > * PageMaps were updated for the session on every request, and held a > reference to the session object. This wasn't needed at all, so this is > a cleanup and efficiency improvement. > > Eelco > > -- View this message in context: http://www.nabble.com/why-are-we-suddenly-creating-2-request-cycles--tf3557832.html#a9995066 Sent from the Wicket - Dev mailing list archive at Nabble.com.
