Sean, > 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 looked at JavaDoc: http://java.sun.com/j2ee/javaserverfaces/1.1_01/docs/api/javax/faces/app lication/StateManager.SerializedView.html Matthias > 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 > > > > > > > > > > > > > > > >
