I further investigated the reason *why* there was an extra "/" at the end and stumbled upon an issue https://issues.apache.org/jira/browse/WICKET-765. Apart from the compatibility with wicket 1.2 I see no rationale for trailing "/". There are even more Strategies that need to be changed. Looking at them I came to the conclusion that the "append("/")" is being overused and redundant especially when it is preceded by the following code which makes sure that the "/" is in place before adding another parameter name-value pair: if (!url.endsWith("/")) { url.append("/"); }
I opened a jira issue on that and attached proposed patch addressing all (hopefully) possible places in code that generate extra trailing "/" in the urls. See: https://issues.apache.org/jira/browse/WICKET-2065 regz, /dd 2009/1/30 Igor Vaynberg <[email protected]>: > can you open a jira issue please...feel free to attach any tests you have. > > -igor > > On Fri, Jan 30, 2009 at 12:33 PM, Dominik Drzewiecki > <[email protected]> wrote: >> Yep, the problem persists for the wicket built from trunk. >> >> /dd >> >> 2009/1/30 Igor Vaynberg <[email protected]>: >>> what wicket version are you using and have you tried with latest from svn? >>> >>> -igor >>> >>> On Fri, Jan 30, 2009 at 6:49 AM, <[email protected]> wrote: >>>> Is it OK (ie "by design" as opposed to "by mistake") that the urls >>>> generated >>>> for the mounted pages end up with the "/"? >>>> >>>> Provided that there's a page that expects single parameter (here: >>>> "content")... >>>> public class HelpPage extends WebPage { >>>> public HelpPage(PageParameters p) { >>>> super(p); >>>> add(new DynamicContentPanel("contentPanel", new >>>> Model<String>(p.getString("content")))); >>>> } >>>> } >>>> >>>> ...and it is mounted in the Application#init() >>>> mount(new BookmarkablePageRequestTargetUrlCodingStrategy("help", >>>> HelpPage.class, null)); >>>> >>>> ...and further referred to somewhere else as: >>>> add(new BookmarkablePageLink("helpPage", HelpPage.class, new >>>> PageParameters("content=a"))); >>>> >>>> the url in the generated markup is in the following form: >>>> http://localhost:8080/dummy-web/help/content/a/;jsessionid=11624C6125F8DF4867E3218676D79A29 >>>> >>>> While IMHO it should read: >>>> http://localhost:8080/dummy-web/help/content/a;jsessionid=11624C6125F8DF4867E3218676D79A29 >>>> >>>> The page parameter for both cases is resolved correctly by the HelpPage's >>>> constructor, so it seems that even though there's an extra "/" at the end >>>> of >>>> the url it gets omitted. >>>> Then why bother generating it? >>>> >>>> I looked up in the sources and found that it is the >>>> AbstractRequestTargetUrlCodingStrategy#appendValue(AppendingStringBuffer >>>> url, String key, String value) that is responsible for adding an extra >>>> trailing "/" at the end of the generated url >>>> It is invoked in the loop, and possibly there's no corner case implemented >>>> for the last parameter to be encoded. >>>> >>>> /regz, >>>> Dominik Drzewiecki >>>> >>> >> >
