You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jean-Baptiste Quenot <jb...@apache.org> on 2006/11/22 12:11:05 UTC
Reopen WICKET-95 Backport of Header contribution filtering to 1.x?
Hi,
I applied the patch located in the issue WICKET-95 to Wicket 1.2.3
with success. But then when starting the webapp I had this error
on my SignIn page in DEVELOPMENT mode:
NotSerializableException: wicket.response.StringResponse
Applying the attached patch against wicket-1.x fixes the problem.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Reopen WICKET-95 Backport of Header contribution filtering to 1.x?
Posted by Eelco Hillenius <ee...@gmail.com>.
Oh, actually I made the StringResponse serializable yesterday as I
thought it was temporarily set somewhere else. But now... I don't know
what I was thinking as indeed Matej, that doesn't solve the fact that
that response shouldn't be in there in the first place. It is a show
stopper though.
Eelco
On 11/22/06, Jean-Baptiste Quenot <jb...@apache.org> wrote:
> * Matej Knopp:
>
> > I believe that patch wasn't meant to be applied against
> > 1.2.3. It's should be applied against 1.x (1.3), which I believe
> > it already was.
> >
> > Making StringResponse serializable is not a good idea IMHO, as
> > the problem is somewhere else. The response classes should never
> > be stored in session.
>
> AFAICT the StringResponse is part of the ResponseHeader, as Wicket
> is adding this to the header:
>
> <script type="text/javascript" ><!--/*--><![CDATA[/*><!--*/
> if (window.name=='') { window.name="wicket:default"; }
> /*-->]]>*/</script>
> --
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>
Re: Reopen WICKET-95 Backport of Header contribution filtering to 1.x?
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Matej Knopp:
> I believe that patch wasn't meant to be applied against
> 1.2.3. It's should be applied against 1.x (1.3), which I believe
> it already was.
>
> Making StringResponse serializable is not a good idea IMHO, as
> the problem is somewhere else. The response classes should never
> be stored in session.
AFAICT the StringResponse is part of the ResponseHeader, as Wicket
is adding this to the header:
<script type="text/javascript" ><!--/*--><![CDATA[/*><!--*/
if (window.name=='') { window.name="wicket:default"; }
/*-->]]>*/</script>
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Reopen WICKET-95 Backport of Header contribution filtering to 1.x?
Posted by Johan Compagner <jc...@gmail.com>.
the page should be detached when it is stored in the session.
Where doesn't that happen?
johan
On 11/27/06, Jean-Baptiste Quenot <jb...@apache.org> wrote:
>
> * Matej Knopp:
>
> > I believe that patch wasn't meant to be applied against
> > 1.2.3. It's should be applied against 1.x (1.3), which I believe
> > it already was.
>
> It is not meant to be applied against 1.2.3, but I need it.
>
> > Making StringResponse serializable is not a good idea IMHO, as
> > the problem is somewhere else. The response classes should never
> > be stored in session.
>
> Apparently, the needed change is also to detach the Page when it
> is stored in the session to avoid storing the header. It is part
> of the «stateless support» refactoring that has been done in
> branch 1.x, I found the interesting change in HttpSessionStore:
>
>
> http://svn.apache.org/viewvc/incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/HttpSessionStore.java?r1=473516&r2=473515&pathrev=473516
> --
> Jean-Baptiste Quenot
> aka John Banana Qwerty
> http://caraldi.com/jbq/
>
Re: Reopen WICKET-95 Backport of Header contribution filtering to 1.x?
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
* Matej Knopp:
> I believe that patch wasn't meant to be applied against
> 1.2.3. It's should be applied against 1.x (1.3), which I believe
> it already was.
It is not meant to be applied against 1.2.3, but I need it.
> Making StringResponse serializable is not a good idea IMHO, as
> the problem is somewhere else. The response classes should never
> be stored in session.
Apparently, the needed change is also to detach the Page when it
is stored in the session to avoid storing the header. It is part
of the « stateless support » refactoring that has been done in
branch 1.x, I found the interesting change in HttpSessionStore:
http://svn.apache.org/viewvc/incubator/wicket/branches/wicket-1.x/wicket/src/main/java/wicket/protocol/http/HttpSessionStore.java?r1=473516&r2=473515&pathrev=473516
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: Reopen WICKET-95 Backport of Header contribution filtering to
1.x?
Posted by Matej Knopp <ma...@knopp.sk>.
I believe that patch wasn't meant to be applied against 1.2.3. It's
should be applied against 1.x (1.3), which I believe it already was.
Making StringResponse serializable is not a good idea IMHO, as the
problem is somewhere else. The response classes should never be stored
in session.
-Matej
Jean-Baptiste Quenot wrote:
> Hi,
>
> I applied the patch located in the issue WICKET-95 to Wicket 1.2.3
> with success. But then when starting the webapp I had this error
> on my SignIn page in DEVELOPMENT mode:
>
> NotSerializableException: wicket.response.StringResponse
>
> Applying the attached patch against wicket-1.x fixes the problem.
>
>
> ------------------------------------------------------------------------
>
> Index: src/main/java/wicket/response/StringResponse.java
> ===================================================================
> --- src/main/java/wicket/response/StringResponse.java (revision 477098)
> +++ src/main/java/wicket/response/StringResponse.java (working copy)
> @@ -17,6 +17,7 @@
> package wicket.response;
>
> import java.io.OutputStream;
> +import java.io.Serializable;
>
> import wicket.Response;
> import wicket.util.string.AppendingStringBuffer;
> @@ -28,7 +29,7 @@
> *
> * @author Jonathan Locke
> */
> -public class StringResponse extends Response
> +public class StringResponse extends Response implements Serializable
> {
> /** StringWriter to write to */
> protected final AppendingStringBuffer out;