Thanks for the quick response. Do you know if there's a way to tell Java which parts of an object are vital during serialization and which can be ignored. I'm thinking about how Detachable Models work.
Am I correct in assuming that if I do not correct this my app will continue to work in a single JVM environment but it will probably not work in a clustered environment? -S2 -- Steve Moitozo II Manager of Web Technology Bates College 207-786-6266 Get the Bates College CA Certificate at: http://www.bates.edu/ils/offices/web/crypto/ Igor Vaynberg wrote: > this is not a requiremenet of wicket per se but that of the servlet > containers. anything you keep in http session must be serializable. since > wicket keeps most of its entities in session they must be serializable. > > when you set level to debug you tripped this: > HttpSessionStore:47 > public void setAttribute(Request request, String name, Object value) > { > // Do some extra profiling/ debugging. This can be a great help > // just for testing whether your webbapp will behave when using > // session replication > if (log.isDebugEnabled()) > > the code inside the if block will try to serialize whatever you are trying > to put into session immediately so there are no surprises during > replication. > > there is no alternative as far as i know, simply a requirement that must be > followed when dealing with java webapps and storing things in session. > > -Igor > > > > On 7/18/06, Steve Moitozo <[EMAIL PROTECTED]> wrote: >> >> I just changed the log4j log level for wicket to DEBUG and now my >> application craps out with the following error: >> >> Internal error cloning object. Make sure all dependent objects implement >> Serializable. Class: mystuff.wicketapp.MyWebSession >> >> Am I to assume that the entire hierarchy of class properties contained >> within MyWebSession must implement Serializable? If so can you offer any >> alternatives? >> >> Why does my app still work when the log level is set higher? I guess the >> real question is does it really work? I haven't tested clustering and >> state replication. I would assume that the above error would cause state >> replication to fail. True? >> >> >> -S2 >> -- >> Steve Moitozo II >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share >> your >> opinions on IT & business topics through brief surveys -- and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Wicket-user mailing list >> Wicket-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wicket-user >> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > ------------------------------------------------------------------------ > > _______________________________________________ > Wicket-user mailing list > Wicket-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-user
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
