Its good to know that the workaround works but as Kalle suggested its probably not ultimately the correct solution.
Matthias, I'm confused about your question regarding SerializedView and the spec? Is SerializedView part of the JSF API? I don't see it anywhere in sun's javadocs. Maybe this is something they are using internally in the RI? I think there is something seriously weird going on here. I will start investigating this now that I'm putting the finishing touches on forceId. sean On Sat, 15 Jan 2005 10:36:00 +0100, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > Kalle and others, > > > 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 > > I did exactly the same. Now, in my app (which uses server site state) > there is no exception more. > > Btw. do this changes break with the spec? > Because of JavaDoc @ SUN shows, that SerializedView > doesn't implement Serializable interface. > > Is it ok to *live* with this workaround, until > JSF 1.2 is published? > Manfred said: > "client and server side state saving will be more compatible > and Serializable problems get addressed." > > Thoughts?? > > > -Matthias > > > 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 > > > > > > > > > >
