of course it can or should be transient
But that does hide a bug then if it keeps being there between request. (that
would be a "leak")
johan
On 10/5/06, Juergen Donnerstag <[EMAIL PROTECTED]> wrote:
But headerResponse can be transient as well. It is/should only be used
during the render process and doesn't change in between requests.
Juergen
On 10/5/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> no httpsessionstore should detach everything of the page.
> Doesn't it do that? Because pages should be stored on disk comletely
> detached.
>
> johan
>
>
> On 10/5/06, Jan Vermeulen <[EMAIL PROTECTED]> wrote:
> >
> >
> > It does get cleared when RequestCycle calls detach(), but that happens
> > AFTER
> > the touch() of the session where the page is stored in the
sessionStore.
> > So
> > the store fails, because HttpSessionStore intents to serialize in its
> > setAttribute().
> >
> > I made 'headerResponse' transient in my workspace, and it solves my
> > problem.
> > Could this be done in Wicket ? For now, I can't use HttpSessionStore
> > without
> > this change.
> >
> > Jan.
> >
> >
> > Matej Knopp wrote:
> > >
> > > No matter what response is stored in header response, it should be
> > > cleared at the end of request - HeaderContainer.onDetach cleans it.
This
> > > detach should be done before detaching it. If it's not, then there
is a
> > > problem.
> > >
> > > -Matej
> > >
> > > Jan Vermeulen wrote:
> > >> I have been investigating a little, and I thing we`re talking about
a
> > bug
> > >> here.
> > >>
> > >> The component that is holding a reference to a Response is
> > >> 'wicket.markup.html.internal.HtmlHeaderContainer (in its superclass
> > >> 'wicket.markup.html.internal.HeaderContainer'). That attribute is
not
> > >> transient, and gets lazily initialized:
> > >>
> > >> public IHeaderResponse getHeaderResponse() {
> > >> if (this.headerResponse == null)
> > >> {
> > >> headerResponse = new
> > HeaderResponse(getResponse());
> > >> }
> > >> return headerResponse;
> > >> }
> > >>
> > >> I suppose the problem occurs in the following code of the method
> > >> 'onComponentTagBody()':
> > >>
> > >> // Temporarily replace the web response with a String
> > response
> > >> final Response webResponse = this.getResponse();
> > >>
> > >> try
> > >> {
> > >> final StringResponse response = new
> > StringResponse();
> > >> this.getRequestCycle().setResponse(response);
> > >>
> > >> If the headerResponse is not yet initialized at that time, you
might
> > >> end-up
> > >> with a reference to a StringResponse because that is what is
available
> > on
> > >> the requestCycle at that moment.
> > >>
> > >> I found that the StringResponse instance that HttpSessionStore
tried to
> > >> serialize was the same that was created (temporarily) by the
> > >> HtmlHeaderContainer, and got stored into the 'headerResponse'
> > attribute.
> > >>
> > >> Maybe 'headerResponse' should be transient, or it should be
initialized
> > >> before the response of the requestCycle is switched to a
> > StringResponse.
> > >>
> > >> Jan.
> > >>
> > >>
> > >> Matej Knopp wrote:
> > >>> It shouldn't implement Serializable. It should never get
serialized.
> > The
> > >>> problem might be that you hold reference to response somewhere in
> > your
> > >>> components? (just a quess)
> > >>>
> > >>> -Matej
> > >>>
> > >>> Jan Vermeulen wrote:
> > >>>> I changed the sessionStore of my application (using Wicket 2.0)
to be
> > >>>> 'wicket.protocol.http.HttpSessionStore' i.s.o.
> > >>>> 'wicket.protocol.http.SecondLevelCacheSessionStore' (because I
use
> > >>>> methods
> > >>>> in the AccessStackPageMap that are not supported in the pageMap
of
> > >>>> SecondLevelCacheSessionStore).
> > >>>>
> > >>>> When saving my first page in the HTTPSession, HttpSessionStore
tries
> > to
> > >>>> serialize it and throws the following exception:
> > >>>>
> > >>>> Caused by: java.io.NotSerializableException:
> > >>>> wicket.response.StringResponse
> > >>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> > >>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown
Source)
> > >>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
> > >>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
Source)
> > >>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> > >>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown
Source)
> > >>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
> > >>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
Source)
> > >>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> > >>>> at java.io.ObjectOutputStream.writeArray(Unknown Source)
> > >>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> > >>>> at java.io.ObjectOutputStream.defaultWriteFields(Unknown
Source)
> > >>>> at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
> > >>>> at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
Source)
> > >>>> at java.io.ObjectOutputStream.writeObject0(Unknown Source)
> > >>>> at java.io.ObjectOutputStream.writeObject(Unknown Source)
> > >>>> at
> > >>>> wicket.protocol.http.HttpSessionStore.setAttribute(
> > HttpSessionStore.java:60)
> > >>>> ... 26 more
> > >>>>
> > >>>> Is this a bug in Wicket ? Should StringResponse implement
> > Serializable
> > >>>> ?
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> >
> > --
> > View this message in context:
> >
http://www.nabble.com/wicket.response.StringResponse-not-serializable-%28Wicket-2.0%29-tf2382604.html#a6655919
> > Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >
> >
>
>
