The code in Wicket 1.4.14 is the same. There is still lines that causes problem:

               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());
               }

And I still need my workaround. It seems that nothing outside wicket
can redirect links - without breaking Wicket lifecycle. Even with
workaround I cannot create outbound rule, because then pages lose
state. I would prefer not to create my own url coding strategy, as the
exact form of the link is constructed outside Wicket...

On Tue, Nov 30, 2010 at 6:11 PM, Krzysztof Kowalczyk
<[email protected]> wrote:
> 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