Hi,
On Sun, Oct 30, 2011 at 8:04 PM, bjolletz <[email protected]> wrote:
> Hi!
>
> After som more hours of debugging I finally think I'm starting to understand
> what is happening here. The short version is that I think that this might
> indeed be an example of the forward problem in the case you pointed to
> above. Here is what I think is happening:
>
> * I point my browser to /App/StartPage
>
> * Tomcat *forwards* the request to /LoginPage, just as it's supposed to do
> according to my web.xml. Wicket is not involved in this forwarding.
Good that this is clear now.
>
> * Wicket renders the LoginPage
>
> * Here comes the confusing part... In WebPageRenderer, line 233, Wicket
> creates a new URL stored in a variable called targetUrl2. This URL will have
> an URL parameter, like "LoginPage?123". This URL is then compared to the old
> URL ("LoginPage") (Line 244). The URLs are not equal which results in Wicket
> (for some reason which is not immediately apparent to me) sending a redirect
> (Line 266) to the new URL stored in targetUrl2.
The redirect is made because the current url is not the same as the
target url. If the redirect is not issued then refreshing the page
(F5) will create a new instance of the page instead of reusing the
constructed instance of the stateful page.
>
> * This will eventually result in Wicket calling the Tomcat sendRedirect
> method with argument "LoginPage?123".
>
> To me it seems strange that Wicket first renders all of LoginPage, and then
> decides to redirect to the same page and render everything again. Seems like
> unnecessary work to me, but there may of course be much I dont see here.
Depending on the configured RenderStrategy Wicket will:
- redirect_to_buffer: render the page, store the bytes in a special
cache, do redirect, use the stored response to write it immediately to
the servlet response
- redirect_to_render: do redirect, render the page, write it in the
servlet response
- one_pass_render: render the page and write it immediately in the
servlet response
there are some additional conditions which may also affect the making
of the decision.
>
> As far as I understand, the redirect to "LoginPage?123" might have something
> to do with the page not being stateless, but it seems strange that all pages
> should have to be rendered twice (with a redirect) just because they are not
> stateless.
The second render of the page is executed only if the target url after
the first render is not the same as the initial target url. This
happens only if your page became stateful during rendering. E.g. a
stateful behavior is added at that time.
>
> As I said I guess this could be an example of this issue, though I'm not
> 100% sure:
> https://issues.apache.org/jira/browse/WICKET-4138
>
> If that is the case, do you know when this issue will be fixed?
Please provide a quickstart to test both use cases in this ticket so
it will be easier for us to decide how exactly to fix it.
>
> Thank you!
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Wrong-path-for-resources-on-redirected-login-page-tp3920038p3953772.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
