Yes,
that's fine for YOUR application. YOU only need to suport one app server at a
time and YOU very rarely migrate. It is NOT an option for a generic framework
used by THOUSANDS of people on a range of different servers. WE have to support
the spec and nothing more. If an app server vendor wishes to support XStream
then thats fine but we can't make any assumption that this is the
case.
Please
take time to read my posts more thoroughly. I'm NOT saying the XStream in place
of standard serialization in the application server would break the servlet
spec. I AM saying that making Wicket depend on XStream serialization would break
Wickets contract with the servlet spec!
Please
lets stop wasting any more time on this discussion.
thanks.
Chris
According to your quote below, the container only makes the guarantee that the Serializable closure of their attributes will be preserved. I don't see why using XStream in place of default serialization will break the servlet standard. Furthermore, you are right that right now no one supports these sorts of serialization engines but I don't much mind because I feel they are worth the effort to use even if only Tomcat uses it (and in the future it'll hopefully spread to other containers).
Case in point: if I have classes that are not serializable I have two options:
1) Spend weeks making them serialization *now*, or
2) Use XStream which would take 10 seconds to configure and if I need to migrate to other container in the future handle the serialization work *then*
I'd much rather do work "on demand" rather than "just in case I'll need it in the future". Container migration is something that happens every couple of years, not every couple of weeks.
Gili
--Original Message Text---
From: Christopher Turner
Date: Tue, 8 Mar 2005 17:11:18 +0100
Message 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
