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.
* 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.
* 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.
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.
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?
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]
