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
