you must be using an old wicket version...upgrade to latest 1.4.x

-igor

On Tue, Nov 30, 2010 at 8:34 AM, Krzysztof Kowalczyk
<kowalczyk.krzysz...@gmail.com> wrote:
> As I have already written in previous mail (pointing to exact line
> that cause the errors) - Wicket is falling because it handles
> forwardUrl in incorrect way. It tries to remove "/" and filterPath
> from forwardUrl even though forwardUrl does not contain filterPath. I
> guess that it is because of an assumption that only wicket exists in
> application and no other framework has influence on forwardUrl. I
> don't know what are other cases that are handled by those lines, but
> forwardUrl can have any value and Wicket assume some concrete value.
>
> On Tue, Nov 30, 2010 at 5:24 PM, Igor Vaynberg <igor.vaynb...@gmail.com> 
> wrote:
>> first figure out why its failing - why is wicket generating a wrong
>> url, and then you can determine if its a bug in wicket or somewhere in
>> your configuration.
>>
>> -igor
>>
>> On Tue, Nov 30, 2010 at 2:21 AM, Krzysztof Kowalczyk
>> <kowalczyk.krzysz...@gmail.com> wrote:
>>> Hi,
>>>
>>> We have existing urls in a form:
>>>
>>> /long,and,complex,title,id/new_opinion
>>> /long,and,complex,title,id/something
>>>
>>> or sometimes
>>>
>>> /long,title/id/new_opinion
>>>
>>> The links like "/long,and,complex,title" are managed by fast and
>>> scalable view, and are stateless. Now we are using Wicket in the same
>>> war. It is mounted to "/cms".
>>>
>>> We are trying to replace forms, that are pure evil in the first
>>> technology with wicket based forms. But we need to keep the links
>>> untouched.
>>>
>>> So I created  UrlRewrite (http://www.tuckey.org/urlrewrite/) rules:
>>>
>>> <urlrewrite use-query-string="true">
>>>
>>> <rule>
>>>        <from>^/(.*),(\d+)/new_opinion$</from>
>>>        <to>/cms/new_opinion/id/$2/url/$1</to>
>>> </rule>
>>>
>>> <rule>
>>>        <from>^/(\?wicket.*)</from>
>>>        <to>/cms/$1</to>
>>> </rule>
>>> ...
>>>
>>>
>>> I have a wicket page - that is mounted on "/new_opinion" with enhanced
>>> HybridUrlCodingStrategy with:
>>> - redirectOnBookmarkableRequest = false
>>>
>>> First rule forwards the request to proper place. Wicket gets the
>>> correct requestUri and all the stuff. But the rule does not work if we
>>> have redirectOnBookmarkableRequest = true because Wicket constructs
>>> wrong urls in ServletWebRequest.getRelativePathPrefixToWicketHandler :
>>>
>>>                if (!Strings.isEmpty(forwardUrl))
>>>                {
>>>                        // If this is an error page, this will be /mount or 
>>> /?wicket:foo
>>>                        relativeUrl = forwardUrl.substring(1);
>>>                        relativeUrl = 
>>> relativeUrl.substring(filterPath.length());
>>>                }
>>>
>>> before this fragment Wicket has correct link, after this we get:
>>> "g,and,complex,title,id/new_opinion", or errors (sometimes the link is
>>> shorter and I get array index out of bounds). If method does not throw
>>> exception it returns wrong number of ../ . Unfortunately
>>> redirectOnBookmarkableRequest = false does not solve the problem as
>>> the second rule catches Wicket that are redirected if they hit
>>> bookmarkable page. So this fragment need to be fixed in order to have
>>> working bookmarkable links with UrlRewrite.
>>>
>>> My temporary workaround is custom delegating WebRequest with small hack:
>>>
>>> public String getRelativePathPrefixToWicketHandler() {
>>>        HttpServletRequest httpRequest = getHttpServletRequest();
>>>
>>>        String forwardUrl =
>>> (String)httpRequest.getAttribute("javax.servlet.forward.servlet_path");
>>>        final String filterPath =
>>> (String)httpRequest.getAttribute(WicketFilter.FILTER_PATH_ATTR);
>>>
>>>        if (!Strings.isEmpty(forwardUrl))
>>>        {
>>>                int count = forwardUrl.split("/").length;
>>>
>>>                String string = "";
>>>
>>>                for (int i = 1; i < count; i++) {
>>>                        string += "../";
>>>                }
>>>
>>>                return string + filterPath;
>>>        }else {
>>>                return wrappedReqest.getRelativePathPrefixToWicketHandler();
>>>        }
>>> }
>>>
>>> I guess it will not work in all cases though...
>>>
>>> If there is a different way of doing url rewriting? If not, I consider
>>> it a bug in Wicket.
>>>
>>> Regards,
>>> Krzysztof Kowalczyk
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to