it doesn't work that way anymore. please read session.java and pagestate code before continuing.
Gili wrote:
Food for thought... in the steps mentioned below, it says that the servlet retrieves and stores the session. Now, I know there is no guarantee that readObject(), writeObject() will get used (which really ruins things!) but for a moment lets say it did (I assume the majority of web containers do anyway). Then you could simply override writeObject(), readObject() for your session object and have it piggypack XStream, calling it in-turn to load/save the actual session.
Is there a way for us to hook into the underlying serialization method without having to rely on read/writeObject() which might not get called?
Gili
--Original Message Text--- *From:* Christopher Turner *Date:* Tue, 8 Mar 2005 17:29:04 +0100
- request arrives at application server
- application server finds the JSESSIONID cookie and retrieves the session from somewhere (memory, disk, cache server etc.)
- the target servlet is identified and the objects are sent to this for processing
- Wicket code runs
- the servlet returns
- the application server looks to see if the session is changed and synchronizes the session across the cluster
- the application server stores the session away somewhere (memory, disk, cache server etc.)
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
