Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 6.1.0
    • Fix Version/s: 6.7.0
    • Component/s: None
    • Labels:
      None

      Description

      In method renderRelativeUrl in UrlRenderer the check url.isAbsolute() is removed. For wich reason is this removed? Because now our relativeurls link /js/name.js are rendered ./js/name.js

      How can I fix this?

      The url is made by Url.parse("/js/name.js").

      1. 4903.tgz
        21 kB
        Martin Grigorov
      2. TestRelativeUrls.zip
        23 kB
        Ann Baert

        Activity

        Hide
        Martin Grigorov added a comment -

        UrlResourceReference has been improved to render its url as is. it wont be recalculated against the base url (the currently rendered page url).

        Show
        Martin Grigorov added a comment - UrlResourceReference has been improved to render its url as is. it wont be recalculated against the base url (the currently rendered page url).
        Hide
        Marieke Vandamme added a comment -

        Can it be made possible in wicket? This was the case before, and looking at other issues (f.e. WICKET-4502) we aren't the only ones needing it.
        We have over more than 20 hostnames to support.
        http://abc.mysite.com
        http://def.mysite.com
        ..
        The way you propose with the rewriting will be very hard to implement.

        Show
        Marieke Vandamme added a comment - Can it be made possible in wicket? This was the case before, and looking at other issues (f.e. WICKET-4502 ) we aren't the only ones needing it. We have over more than 20 hostnames to support. http://abc.mysite.com http://def.mysite.com .. The way you propose with the rewriting will be very hard to implement.
        Hide
        Martin Grigorov added a comment -

        > Our js need to have the same host and port as the wicket application, otherwise we have problems with crossside js loading.

        But you rewrite http://my.special.cdn.url/js/my.js to http://your.site.com/js/my.js, no ?

        Show
        Martin Grigorov added a comment - > Our js need to have the same host and port as the wicket application, otherwise we have problems with crossside js loading. But you rewrite http://my.special.cdn.url/js/my.js to http://your.site.com/js/my.js , no ?
        Hide
        Marieke Vandamme added a comment -

        We've been looking further into it, and found WICKET-4502.
        There you propose to build the url in the IRequestMapper#mapHandler().
        That's the way we tried to include the links with absolute urls too.
        Our js need to have the same host and port as the wicket application, otherwise we have problems with crossside js loading.
        We tried to render the url as full, by adding the host and port, but wicket removes it and makes it relative.
        Thanks for looking into this once more.

        Show
        Marieke Vandamme added a comment - We've been looking further into it, and found WICKET-4502 . There you propose to build the url in the IRequestMapper#mapHandler(). That's the way we tried to include the links with absolute urls too. Our js need to have the same host and port as the wicket application, otherwise we have problems with crossside js loading. We tried to render the url as full, by adding the host and port, but wicket removes it and makes it relative. Thanks for looking into this once more.
        Hide
        Marieke Vandamme added a comment -

        Sorry for that !
        It's sometimes hard for us to describe a usecase that is so clear for us, but indeed not always for somebody else.
        Thanks for the time, and we'll try harder to explain in the future.

        About the jira issue, we'll try with full url's instead.
        This worked in 1.5.8 and 6.0.0, so we thought it was a bug.
        But now we know that it's just not supported anymore.

        Show
        Marieke Vandamme added a comment - Sorry for that ! It's sometimes hard for us to describe a usecase that is so clear for us, but indeed not always for somebody else. Thanks for the time, and we'll try harder to explain in the future. About the jira issue, we'll try with full url's instead. This worked in 1.5.8 and 6.0.0, so we thought it was a bug. But now we know that it's just not supported anymore.
        Hide
        Martin Grigorov added a comment - - edited

        Please give more details in the initial report. I spend my time debugging what is the use case.

        Since you rewrite the url then I think you can use absolute urls like CDN ones - http://my.special.cdn.url/js/myjs.js. mod_rewrite can transform this to whatever you actually need.
        That is TestResourceReference should use UrlResourceReference dependencies with fully qualified urls like the one above.

        Show
        Martin Grigorov added a comment - - edited Please give more details in the initial report. I spend my time debugging what is the use case. Since you rewrite the url then I think you can use absolute urls like CDN ones - http://my.special.cdn.url/js/myjs.js . mod_rewrite can transform this to whatever you actually need. That is TestResourceReference should use UrlResourceReference dependencies with fully qualified urls like the one above.
        Hide
        Marieke Vandamme added a comment -

        I think there is a misunderstanding..
        Our javascript isn't inside our webapp-directory.

        For example:
        www.mysite.com/mywicketproject/index.html
        www.mysite.com/js/myjs.js

        But we don't want to include the js as "www.mysite.com/js/myjs.js", but as "/js/myjs.js".
        The linking of the js is dealed with in apache / varnish.

        Show
        Marieke Vandamme added a comment - I think there is a misunderstanding.. Our javascript isn't inside our webapp-directory. For example: www.mysite.com/mywicketproject/index.html www.mysite.com/js/myjs.js But we don't want to include the js as "www.mysite.com/js/myjs.js", but as "/js/myjs.js". The linking of the js is dealed with in apache / varnish.
        Hide
        Martin Grigorov added a comment -

        I believe what you need is something like this.

        Show
        Martin Grigorov added a comment - I believe what you need is something like this.
        Hide
        Marieke Vandamme added a comment -

        Is that something that can be solved at our side?
        Or should it be something provided through the wicket framework, a new method in JavaScriptUrlReferenceHeaderItem?

        We need this functionality for all our javascript includes. Because this javascript doesn't reside in our project code and we don't want to run against crossdomain loading problem.

        Thanks !

        Show
        Marieke Vandamme added a comment - Is that something that can be solved at our side? Or should it be something provided through the wicket framework, a new method in JavaScriptUrlReferenceHeaderItem? We need this functionality for all our javascript includes. Because this javascript doesn't reside in our project code and we don't want to run against crossdomain loading problem. Thanks !
        Hide
        Sven Meier added a comment -

        Maybe the following line in your code is the cause of a misunderstanding:

        response.render(JavaScriptUrlReferenceHeaderItem.forReference(TestResourceReference.get()));

        You're calling the static method JavaScriptHeaderItem#forReference(), probably thinking that this will generate an absolute Url as JavaScriptUrlReferenceHeaderItem's javadoc promises. But all this does is creating a JavaScriptReferenceHeaderItem, which uses a relative Url (as almost anything in Wicket).

        Show
        Sven Meier added a comment - Maybe the following line in your code is the cause of a misunderstanding: response.render(JavaScriptUrlReferenceHeaderItem.forReference(TestResourceReference.get())); You're calling the static method JavaScriptHeaderItem #forReference(), probably thinking that this will generate an absolute Url as JavaScriptUrlReferenceHeaderItem's javadoc promises. But all this does is creating a JavaScriptReferenceHeaderItem, which uses a relative Url (as almost anything in Wicket).
        Hide
        Martin Grigorov added a comment -

        Please provide a quickstart that demonstrates the use case.
        The method name says that the result is a relative url. UrlRenderer also provides #renderFullUrl() and #renderContextRelativeUrl().
        The change has been made for solving WICKET-4645.

        Show
        Martin Grigorov added a comment - Please provide a quickstart that demonstrates the use case. The method name says that the result is a relative url. UrlRenderer also provides #renderFullUrl() and #renderContextRelativeUrl(). The change has been made for solving WICKET-4645 .

          People

          • Assignee:
            Martin Grigorov
            Reporter:
            Ann Baert
          • Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development