> -----Original Message----- > From: Manfred Geiler [mailto:[EMAIL PROTECTED] > Subject: Re: Exception during server-side state saving > Why do you want to have JspStateManagerImpl serializable?! > From what I see from the code, the only thing that has to be > Serializable is the SerializedView.
Because of the simple fact that you get/used to get exceptions when restarting the container / reloading your application context if it's not serialized. But please read my previous email again; I've tried to describe the problem there as clearly as possible, and I really *don't* suggest making it serializable. And Sean, yes, you get the exceptions only when using server side state saving. Kalle > BTW, the whole state saving thing is currently beeing > refactored in JSF 1.2, so that client and server side state > saving will be more compatible and Serializable problems get > addressed. > > Manfred > > > Korhonen, Kalle schrieb: > >>-----Original Message----- > >>From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] > >>Subject: RE: Exception during server-side state saving BTW. > >>javax.faces.application.StateManager.SerializedView > >>(inner class) is serializable IN myfaces! > >>But I guess it shouldn't. See > >>JavaDoc for JSF API @ SUN > > > > > > Ah. I didn't even compare the old code with the latest. > Maybe that's > > the solution then, at least for the short term, to have > SerializedView > > and JspStateManagerImpl Serializable, maybe with attributes > non-transient. > > In the long run, maybe we can do something more elegant in > the context > > listener, ie. to remove the objects from the session that > shouldn't be > > serialized when the context is about to be destroyed. Thanks for > > looking into the issue Matthias, I seriously don't have > time to deal > > with it right now. And so far, it's been mostly just an > annoyance to > > us, not a showstopper. > > > > Kalle > > > > > >>But spec says nothing on that, > >>I guess (a time ago I looked inside that issue...) > >> > >>Also thanks for mailing it to the list! > >> > >>BTW. I mailed to infrastructure guys @apache, after we leave > >>incubator, they change it... > >> > >>Ted brings this up to PMC of incubator. > >> > >> > >>>-----Original Message----- > >>>From: Korhonen, Kalle [mailto:[EMAIL PROTECTED] > >>>Sent: Thursday, January 13, 2005 10:13 PM > >>>To: MyFaces Development > >>>Subject: RE: Exception during server-side state saving > >>> > >>> > >>>Hi, > >>> > >>>I wrote this (read below) in the comments of bug JIRA MYFACES-75 > >>>(exception during server-side state saving). Thought it might be > >>>useful to send it to the list as well, cause I surely don't know > >>>what's the proper way to fix this.. Anybody got any good ideas? > >>> > >>>Kalle > >>> > >>>--- > >>>I believe servlet spec 2.3 requires that a container is able to > >>>serialize the session for persistence. In Tomcat, you can > >> > >>configure a > >> > >>>session.PersistentManager to not try to store the session > >> > >>on disk by > >> > >>>setting its attribute "saveOnRestart" to false. The attribute by > >>>default is true, which causes the whole problem. > >>> > >>>Just marking JspStateManagerImpl serializable isn't enough > >> > >>to fix the > >> > >>>problem. When I was working with sourceforge codebase, I > >>>experimentally hacked and successfully fixed the problem with these > >>>steps: > >>>- marked ...application.jsp.JspStateManagerImpl Serializable > >>>- marked its private member _renderKitFactory transient > >>>- marked > >> > >>javax.faces.application.StateManager.SerializedView (an inner > >> > >>>class) Serializable > >>>- marked its private members _structure and _state transient > >>> > >>>However, I never made a patch for it, because I seriously > >> > >>doubt that > >> > >>>making these changes is the correct way of solving the > >> > >>problem. If you > >> > >>>make the private members transient, it prevents the > >> > >>serialization of > >> > >>>backing beans in session scope. It might also be that > backing beans > >>>shouldn't be included when the container is trying to > serialize the > >>>session, but not sure. > >>> > >>>I guess the view is stored in session for being able to > restore it, > >>>but when the container is shutting down, it should be > >> > >>removed from the > >> > >>>session. I don't think it should be serializable at all. About the > >>>StateManager, I'm not too sure if it should or not. > >>>Surely we shouldn't throw an exception of StateManager not being > >>>Serializable, but I would almost leave some exception there > >> > >>or, better > >> > >>>yet, a descriptive error message, and just force the users > >> > >>to either > >> > >>>configure their containers correctly or deal with it some > other way. > >>> > >>> > >>>>-----Original Message----- > >>>>From: Sean Schofield [mailto:[EMAIL PROTECTED] > >>>>Sent: Saturday, January 08, 2005 3:07 PM > >>>>To: MyFaces Development > >>>>Subject: Re: Exception during server-side state saving > >>>> > >>>>Matthias, > >>>> > >>>>Then it seems like additional classes need to be made > >> > >>Serializable. > >> > >>>>My application was *very* simple so I didn't run into > >> > >>this problem. > >> > >>>>I still think you need my patch b/c if you take it out, it will > >>>>complain that JspStateManagerImpl can't be serialized. > >>>> > >>>>I don't know enough about MyFaces yet to know why > >>>>JspStateManagerImpl should be serialized. I suspect > >> > >>somewhere the > >> > >>>>code is trying to store it in the session. The solution > >> > >>is to stop > >> > >>>>requiring that it be serialized or fix all of the > >> > >>potential things > >> > >>>>that could be stored in JspStateManagerImpl and make them > >>>>serializable as well. > >>>> > >>>>I will try to look into it. > >>>> > >>>>Regards, > >>>>sean > >>>> > >>>> > >>> > >> > > > > > >
