Makes sense, and thanks for the quick replies. The situation that I'm dealing with most commonly is where I'm dealing with simple, DTO-like POJOS with no-arg constructors and getters/setters (why they are not serializable in the first place is beyond me). It just seems like it would be possible, in this simple case, to create a proxy for each object in the object graph which is not serializable until you get down to the actual data (i.e. primitives, Strings, etc.) which is serializable. The proxies would have to keep track of whatever information they need to de-serialize themselves (e.g. class name and constructor). It seems like this has not been implemented, but do you think it is possible to do so?
-Chris On Tue, Mar 3, 2009 at 9:43 PM, Igor Vaynberg <[email protected]> wrote: > objects you put into the model are stored in components, which are in > turn stored in httpsession and are serialized to disk. in order to be > serialized to disk or to be stored in httpsession (per servlet spec) > those objects must be serializable. > > if your object is not serializable and all you do is wrap it in a > serializable proxy this will not help you much when it comes to dump > the page to disk. > > what is happening in wicket-guice and wicket-spring is that only > references you get from your container are held us serializable > proxies. this works because when it comes time to serialize the > component these values can be discarded because they can be later > looked up from the container again. but if your value is not > discardable this approach wont work. > > makes sense? > > -igor > > On Tue, Mar 3, 2009 at 8:36 PM, Chris Hansen <[email protected]> wrote: >> Hi all, >> >> First off, I'm new to Wicket and I have to say I'm really liking it so far. >> >> One concern I have is related to using non-serializable objects. If >> I'm not mistaken, some other web frameworks will create dynamic, >> serializable proxies for your non-serializable objects automatically, >> when possible. I saw that this type of functionality is used in >> Wicket's Guice integration, but I am wondering why it isn't a part of >> Wicket proper. Using serializable model objects seems like a fine >> goal, but what if those model objects are in a library which is not >> under our control and they happen to not be serializable? >> >> There must be downsides to the proxy approach that I'm not aware of, >> or an easier way to work with non-serializable model objects. Am I >> missing something? >> >> Thanks, >> Chris >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
