Yes, we are ok, we should put Serializable in session. (But put Serializable
in Session doesn't mean to put Serialized in Session)

And it seems that wicket Serialize each Page one by one. This way if you
have a single object instance that you share between pages as object
property, after pages serialization, if you have ten page referencing your
object you will have ten copies of your object, while you think you have
only one. It's a known serialization drawback. And it's what I want to get
arround, when Serialization is not needed.

I'will look for HttpSesssionStore.

Thanks.

2009/12/8 Marat Radchenko <slonopotamusor...@gmail.com>

> 2009/12/8 Yves-Marie LAINÉ <ymla...@gmail.com>:
> > Hi,
> >
> > I'm new on the list, sorry if my question has already been asked. I
> didn't
> > find the right answer on google.
> >
> > Is it possible tu use wicket without Page serialization ?
> It is. Use only stateless components.
>
> > Technically, is it possible to imagine a SimpleHttpSessionPageStore that
> > don't serialize objects and keep them as they are in session, like it's
> done
> > in others frameworks ?
> Logic flaw: session contents CAN get serialized. Read Servlet spec,
> you shouldn't put non-serializable stuff in session.
>
> > But... I'm working on an app that consist of few pages, not versioned (no
> > need of the back button support), because I need to keep page state
> through
> > navigation, I keep pages references created, avoiding creation of a new
> page
> > instance when back on a visited page.. I don't need to write anything on
> > disk, the session space is enough.
> Same flaw.
>
> > This way, i wanted to share a data object instance between pages (as
> class
> > member), for modification. But due to the Page Serialization the object
> > identity is broken.
> That just means your data object serialization is broken.
>
> Sidenote: you can use HttpSessionStore (instead of
> SecondLevelCacheSessionStore) to make wicket store everything in
> session (but not in it's custom wicket on-disk store)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Reply via email to