myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Wessendorf" <maili...@matthias-wessendorf.de>
Subject FW: Exception during server-side state saving
Date Sat, 15 Jan 2005 18:48:35 GMT
ups...

-----Original Message-----
From: Matthias Wessendorf [mailto:mailings@matthias-wessendorf.de] 
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
> <mailings@matthias-wessendorf.de> 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
> > > <mailings@matthias-wessendorf.de> 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:sean.schofield@gmail.com]
> > > > > > 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
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > 
> >
> 


Mime
View raw message