> > Let the application object create the web request,set the application > > thread local, get the session, create a custom response object (this > > is where you probably want to capture your output, see for instance > > BufferedWebResponse) and then let the session create a request cycle > > (which is not meant for reuse mind you) using those request and > > response objects. Execute the request cycle ( cycle.request()) and then > > do something with the response object that should now hold the render > > result. And don't forget to cleanup. > > Although I basically understand what you are saying, I don't see how this > helps me to > create something like a new page in another thread, since the session will > attempt to access > the request cycle in this thread. Or I should create a new request cycle in > that thread?
You should create the new request cycle and everything else in that thread. > Why is there no set methods on the request cycle like there is for session > and application? Yes, that is an interesting point. Just grew like that I guess. But having a set method wouldn't really help your case, right? > And why is the get method on the request cycle final? I would like to use > covariant return types > for my custom request cycle, like I can do for application and session. Agreed. This was already the case for the 2.0 code base. But the get is non-final for 1.3 now as well. Thanks, Eelco ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
