if gili wants to go test our new PageState mechanism by making a nice subclass of PageState using xstream (XStreamPageState?), that might make a really nice contrib or extensions class...
Christopher Turner wrote:
Erm, how is that of any use to a generic web framework? People are going deploy Wicket applications on Tomcat, Jetty, JRun, Websphere, Weblogic, Pramati, Oracle/Orion and possibly many others. I doubt every one of these vendors is going to switch to XStream. The best we can ever do is support the SERVLET 2.4 specification because that is the only given in every environment.
Could I therefore politely request that we (you) forget about XStream or any other approach that is not compatible with the servlet specification. That way we can spend our time solving the problem in a realistic and portable way.
Regards,
Chris
Chris,
Ok, so I filed a RFE with Tomcat to add XStream support (ability to use it instead of the default mechanism). Although, I don't have much confidence in the Tomcat crowd anymore :(
Thanks, Gili
--Original Message Text--- *From:* Christopher Turner *Date:* Tue, 8 Mar 2005 16:45:46 +0100
Message The reason for not using something like XStream is that we don't have any control over the serialization of objects in the session. This is entirely the responsibility of the application server and clustering engine. It is not something that we have any option to override. For a typical request the following happens:
- 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.)
Everything related to session storage, synchronization and so on happens IN the application server code base so we really have ascolutely no control over this. In fact there is no guarantee that the application server will even use the standard Java serialization mechanism in its own implementation. To quote the Servlet 2.4 specification:
"If distributed containers persist or migrate sessions to provide quality of service features, they are not restricted to using the native JVM Serialization mechanism for serializing HttpSessions and their attributes. Developers are not guaranteed that containers will call readObject and writeObject methods on session attributes if they implement them, but are guaranteed that the Serializable closure of their attributes will be preserved."
Therefore anything other than making sure objects implement Serializable is not possible!
regards, Chris
Again coming back to this point: why are we not using XStream that allows us to handle everything automagically?
Gili
--Original Message Text--- *From:* Johan Compagner *Date:* Tue, 08 Mar 2005 15:49:18 +0100
because the model itself will still be serialized. A detachable model doesn't mean the model itself is detached but the developer can detach the contents.
For example if you have a heavy weight component in your model that you can relookup from somewhere by an ID. Then in the detach you store that id in a non transient instance reference. And youre heavy weight object is cleared or hold only in a transient reference.
Then when the component and its model are serialized only the id is serialized with the model not youre complete object.
johan
Cameron Braid wrote: Speaking about serializable stuff...
With detachable models, why do they also have to be serializable ?
Cameron.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:wicket-develop- [EMAIL PROTECTED] On Behalf Of Johan Compagner Sent: Wednesday, 9 March 2005 12:28 AM To: Wicket Developer List Subject: [Wicket-develop] should we make AbstractResource serializeable or not?
Our clone by serialize did encounter a few serialization exceptions for example all the Resources (like image). Should we make AbstractResource serializeable? those can be in the session..
johan
------------------------------------------------------- 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
------------------------------------------------------- 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
------------------------------------------------------- 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
