Thanks John, Let me take this one step farther, just to clarify.
I know that in a standard web application, the web container can Serialize user HttpSessions such that one can shut an application down and upon bringing it back up, HttpSession state is restored and, for instance, a user might not have to log back in. This functionality required us to implement Serializable for anything we wanted to store in a user's HttpSession. From your response, is it safe to say that Wicket doesn't use the HttpSession that way - or at least, doesn't store all these pages and their contents out to Session such that there is no requirement from Wicket to use a valid, unique serial id for all these anonymous classes? Including the PageStore or anything else native to Wicket internals? Is there anything, whatsoever that Wicket or Java webapps would require proper serial ids for? -Luther (I hope it's clear, I am intentionally being technical and trying to clarify whether or not such unique serial ids are necessary or required for some dark corner of Wicket functionality vs just not using them because they are a pain or simply can safely be ignored or even left out.) On Sat, Apr 11, 2009 at 12:59 PM, John Krasnay <j...@krasnay.ca> wrote: > On Sat, Apr 11, 2009 at 08:45:31AM -0500, Luther Baker wrote: > > A quick question - is it generally acceptable to use > > > > private static final long serialVersionUID = *1L*; > > > > for most the anonymous inner class I create using Wicket? Specifically, > I'm > > asking about using the value (-1). > > > > I've seen this idiom in the source but wasn't sure if there was some > > rational or serialization concerns I needed to be aware of before > generally > > using (-1) everywhere. > > > > -Luther > > An arbitrary constant (1 or -1) works just as well as any other value. > > Personally, I've disabled that warning in Eclipse and I don't add > serialVersionUID to any of my Wicket components. > > jk > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
