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.
