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]
