Use a loadable detachable model instead (see also wicket in action, chapter re models). and in page.ondetach() detach those models.
Martijn On Thu, Apr 2, 2009 at 1:27 PM, Steve Swinsburg <[email protected]> wrote: > Thanks Martijn, > > Understand re logger and making it a static instance, but what about other > transient fields, is it ok to override getObject on each page an re setup my > transient fields or is this going to cause issues down the track? > > > cheers, > Steve > > > > > > On 2 Apr 2009, at 12:22, Martijn Dashorst wrote: > >> magic word for loggers: static >> >> and your assumption is correct: if you don't do anything, you'll get >> NPE's when you reference a transient field on an object that has been >> deserialized. >> >> Martijn >> >> On Thu, Apr 2, 2009 at 1:17 PM, Steve Swinsburg >> <[email protected]> wrote: >>> >>> All, >>> I have some questions regarding deserialization. On a page in my >>> application, I click a link which takes me to a different page, then >>> click >>> 'back', and try to do something on the original page, but get NPE's >>> whenever >>> any of my transient fields are called. A simple example: >>> private transient Logger log = Logger.getLogger(BasePage.class); >>> Later in my code I use my log object in the onSubmit of a button: >>> log.debug("MySearch() search.getSearchInterest(): " + searchText); >>> Which works fine in the normal workings of the page. If I click away from >>> the page then use the 'back' button to come back to this page, then click >>> the button that will call this same log.debug statement, thats when the >>> NPE >>> occurs. >>> So, am I correct in my understanding that the page is serialized when I >>> click away, de-serialized when I come back, and, since no transient >>> objects >>> are serialized along with it, that my 'log' will be null and this NPE is >>> then correct? >>> If so, this leads me to thinking that, in order for my page to set itself >>> up >>> again correctly, I need to override readObject() and re-setup all of my >>> transient objects that would not be restored in this method? Is this a >>> good >>> or bad practice? >>> It is working correctly I am just after any tips or caveats. >>> ie this works: >>> private void readObject(ObjectInputStream in) throws IOException, >>> ClassNotFoundException { >>> // our "pseudo-constructor" >>> in.defaultReadObject(); >>> // now we are a "live" object again, so let's rebuild >>> log = Logger.getLogger(BasePage.class); >>> >>> } >>> >>> thanks a lot, >>> Steve >>> >>> p.s. >>> Of interest, when I click 'back' in Safari 4, the whole page is >>> reconstructed again (ie the constructor is called again) and readObject >>> is >>> not called, but in other browsers, the state is preserved and >>> readObject() >>> is called. Not sure what the go is with that. >>> ref: >>> http://java.sun.com/developer/technicalArticles/Programming/serialization/ >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> >> -- >> Become a Wicket expert, learn from the best: http://wicketinaction.com >> Apache Wicket 1.3.5 is released >> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
