[
https://issues.apache.org/jira/browse/WICKET-1886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989175#comment-12989175
]
Robert Dahlström commented on WICKET-1886:
------------------------------------------
Just to add to Pedros update:
Wicket version 1.4.15
I actually have not checked against 1.5 RC's
I believe the culprit is in
MockWebApplication.postProcessRequestCycle:
if (httpResponse.isRedirect())
{
lastRenderedPage = generateLastRenderedPage(cycle);
MockHttpServletRequest newHttpRequest = new
MockHttpServletRequest(application, servletSession,
application.getServletContext());
...
}
when the servlet request gets recreated all cookies are cleared (even if the
original request contained cookies). One possible solution would be to copy the
cookies from the original request over to the new redirect request as this
should simulate how it works in the browser. But I could be wrong or lack some
information about this.
> WicketTester Cookie handling
> ----------------------------
>
> Key: WICKET-1886
> URL: https://issues.apache.org/jira/browse/WICKET-1886
> Project: Wicket
> Issue Type: Bug
> Affects Versions: 1.3.5, 1.4-RC1
> Reporter: Jörn Zaefferer
> Assignee: Pedro Santos
> Fix For: 1.3.6, 1.4-RC2
>
> Attachments: CookieTest.java, WICKET-1886.patch,
> WICKET-1886__SecureForm_and_failing_test.patch, patch-WICKET-1886.diff
>
>
> While trying to test my SecureForm implementation
> (https://issues.apache.org/jira/browse/WICKET-1885) with WicketTester I ran
> into this issue: A cookie set in the response never shows up in the "next"
> request, because both have their own lists of cookies that aren't shared.
> Afaik both should share the same List instance to handle cookies. That way
> its possible to set a cookie in the response and read it from the request.
> A simple testcase is attached.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
