Ok, thanks, I will try it tomorrow

On Tue, Nov 30, 2010 at 6:07 PM, Igor Vaynberg <[email protected]> wrote:
> upgrade to 1.4.14 because that code looks different for me.
>
> -igor
>
> On Tue, Nov 30, 2010 at 9:03 AM, Krzysztof Kowalczyk
> <[email protected]> wrote:
>> We use Wicket 1.4.12.
>>
>> On Tue, Nov 30, 2010 at 5:43 PM, Igor Vaynberg <[email protected]> 
>> wrote:
>>> 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
>>> <[email protected]> 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 <[email protected]> 
>>>> 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
>>>>> <[email protected]> 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: [email protected]
>>>>>> For additional commands, e-mail: [email protected]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [email protected]
>>>>> For additional commands, e-mail: [email protected]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [email protected]
>>> For additional commands, e-mail: [email protected]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to