Yeah I'm reading the spec now. I haven't had a chance to dig into the spec yet but this is a good opportunity.
sean On Sat, 15 Jan 2005 19:48:35 +0100, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > ups... > > -----Original Message----- > From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 15, 2005 7:46 PM > To: 'Sean Schofield' > Subject: RE: Exception during server-side state saving > > Sean, > > yes it's part of JSF spec. > > See chapter 7.6.3 page State Saving Methods > > e.g. > > "This method causes the tree structure and component state of the view > contained in the argument FacesContext to be collected, stored, and > returned in a > > StateManager.SerializedView > > instance. If null is returned from this method, > there is no state to save. > public StateManager.SerializedView saveSerializedView(FacesContext > context);" > > and so on, but none about Serializable inside of > StateManager.SerializedView > ... > > HTH, > Matthias > > > I'm not sure if the nested class would be considered part of > > the spec. If it is, its probably a violation to make it > > serializable. Even if it was allowed I don't think we > > should. We must be missing something ... > > > > sean > > > > > > > > On Sat, 15 Jan 2005 19:29:40 +0100, Matthias Wessendorf > > <[EMAIL PROTECTED]> wrote: > > > 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/a > > > pp > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
