On Feb 6, 2008 10:28 AM, Fabrizio Giudici <[EMAIL PROTECTED]> wrote:
>
> >
> > Are you using our modal window implementation or your own?
>
> Wicket implementation. BTW, I have another modal window that doesn't
> create problem. I'll later post the code, when I'm able to cut it down.
are you using it to popup a panel or a page? i think the panel popup
doesnt generally work well, the page version works better. also make
sure you popup the page in a different pagemap.
> >
> >> 3. I have still some confusion about serialization of things
> >> in sessions. I've always got some objects that are not
> >> serializable and caused tons of exceptions in log files, but
> >> no harm other than it. I'm now wondering whether they can
> >> trigger one of the above problems, and anyway before going
> >> into production I'd like to face with this issue in a
> >> definitive fashion. I know about the possibility of using
> >> detachable objects, nevertheless I need first to understand
> >> why this serialization thing can't be disabled - after all
> >> I've got no need for clustering in near future (and if I
> >> should do it, I'd probably go with Terracotta). Also, in
> >> version 1.2 I once saw that there was a UserSession (?)
> >> method that looked like it was useful for disabling
> >> serialization, and I had a mental note about using it, but
> >> it looks like it disappeared in 1.3.0. Hints?
> >
> > Serialization has always been needed in wicket for things other then
> > cluster replication. Versioning has been one of those reasons. We
> > would use serialization mostly for cloning an object, so that we can
> > keep a reference to its previous state for rolling back a version.
> > With 1.3.1 this has changed dramatically. In order to free up session
> > space (1.2 would keep x pages in session) 1.3.1 only keeps the most
> > current page in session and spools older pages to disk via
> > serialization. So if you hit a page that has a serialization problem
> > and later come back to it via back button and click a link/submit a
> > form you will get a page expired error. My recommendation is to make
> > sure you use detachable models or make your objects serializable. In
> > the meantime, try
> >
> > class MyApplication extends WebApplication { ISessionStore
> > newSessionStore() { return new HttpSessionStore();}}
> >
> > that will turn off disk spooling and will make 1.3 behave more like
> > 1.2 in that regard.
>
> Ok, I'll try this just to see if it can at least solve immediately
> the problem, then go for some refactoring. My question is: but if I
> don't need (and don't want) page versioning, and I disable it, is
> serialization still necessary?
sure, you can disable the versioning completely, but then you also
wont have a proper backbutton support. versioning is there for a
reason...
-igor
>
> --
>
> Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog
> [EMAIL PROTECTED] - mobile: +39 348.150.6941
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
