Johan Compagner wrote:
i was running the threadtest App1Test1 which does this"/app1?wicket:bookmarkablePage=one: wicket.threadtest.apps.app1.Home", "/app1?wicket:bookmarkablePage=two: wicket.threadtest.apps.app1.Home", "/app1?wicket:interface=two:${iteration}:link::ILinkListener", "/app1?wicket:interface=one:${iteration}:link::ILinkListener", "/app1?wicket:interface=two:${iteration}:link::ILinkListener" i altered some behaviour in the link.onclick. But then i noticed that the last 3 calls where never called! it is this code first thing in WicketFilter.doGet(_ String relativePath = getRelativePath(servletRequest); // Special-case for home page - we redirect to add a trailing slash. if (relativePath.length() == 0 && !Strings.stripJSessionId( servletRequest.getRequestURI()).endsWith("/")) { String foo = servletRequest.getRequestURI() + "/"; servletResponse.sendRedirect(foo); return; } so when the url doesn't end with / then we send a response to xxx/ What about the params!????
On a production site, this will never happen - once you are into the system all the URLs like that are generated with trailing slashes.
Shouldn't the test be there if there are request params then it is not a request to home??
We should probably rewrite this so that it redirects including the params. I'll go fix that now. It's important that we have a trailing slash for reasons that are complex - if you don't have a filter path it all goes wrong otherwise.
Note that Wicket won't generate URLs like this without a / on the end of them, so this is really only a problem with unit tests that fake all this stuff in (or possibly if people have bookmarks with params in their browser that they expect to work when upgrading from 1.2.x to 1.3, which probably won't work anyway for other reasons).
Al
