Uploaded image for project: 'Wicket'
  1. Wicket
  2. WICKET-4030

HeaderResponse.renderCSSReference does not render context path relative url, but wicket filter url-pattern relative url

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.5-RC7
    • Fix Version/s: 1.5.1
    • Component/s: wicket
    • Labels:
      None

      Description

      In an application with a wicket filter url-pattern different than /*, if you use HeaderResponse.renderCSSReference(String url), where url is a context-path-relative url (css/main.css, for example), the generated css link is not context relative, but wicket url-pattern relative.

      1. quickstart.zip
        20 kB
        Matteo Sotil
      2. relative-url.patch
        4 kB
        Peter Ertl

        Activity

        Hide
        msotil Matteo Sotil added a comment - - edited

        Quickstart of the issue. Execute Start, go to http://localhost:8080/contextPath. If renderCSSReference worked properly, background color should be red (that means css is loaded correctly), but it is not.

        Show
        msotil Matteo Sotil added a comment - - edited Quickstart of the issue. Execute Start, go to http://localhost:8080/contextPath . If renderCSSReference worked properly, background color should be red (that means css is loaded correctly), but it is not.
        Hide
        pete Peter Ertl added a comment -

        The problem is:

        response.renderCSSReference(path) expects a context-relative path (see javadoc). This is not to be confused with the effective path that get's rendered.

        basically what you did wrong is call

        response.renderCSSReference("../css/main.css")

        when instead you should use the context-relative path (relative to "/contextPath" in your sample).

        So the correct method call is

        response.renderCSSReference("css/main.css")

        It will work no matter how you mount your home page or if you mount it at all. In any case wicket will generate the required number of ".." in the path.

        Show
        pete Peter Ertl added a comment - The problem is: response.renderCSSReference(path) expects a context-relative path (see javadoc). This is not to be confused with the effective path that get's rendered. basically what you did wrong is call response.renderCSSReference("../css/main.css") when instead you should use the context-relative path (relative to "/contextPath" in your sample). So the correct method call is response.renderCSSReference("css/main.css") It will work no matter how you mount your home page or if you mount it at all. In any case wicket will generate the required number of ".." in the path.
        Hide
        msotil Matteo Sotil added a comment - - edited

        In fact, response.renderCSSReference("css/main.css") was the first thing I tried, but it did'nt work.

        Now I see that the real condition to reproduce the issue is using a wicket filter url pattern different than /*. I've updated issue summary, description and quickstart to reflect it. In quickstart, I changed wicket filter mapping like this:

        <filter-mapping>
        <filter-name>wicket.myproject</filter-name>
        <url-pattern>/wicket/*</url-pattern>
        </filter-mapping>

        Now context path is /*, HomePage is not mounted, so application url is http://localhost:8080/wicket.
        Now I use response.renderCSSReference("css/main.css") as should be.

        You will see that generated href is css/main.css, wich points to http://localhost:8080/wicket/css/main.css, when it should be ../css/main.css to point to http://localhost:8080/css/main.css, because css path passed to renderCSSReference should be context-relative path, and not wicket-filter-url-pattern relative, isn't it?.

        Show
        msotil Matteo Sotil added a comment - - edited In fact, response.renderCSSReference("css/main.css") was the first thing I tried, but it did'nt work. Now I see that the real condition to reproduce the issue is using a wicket filter url pattern different than /*. I've updated issue summary, description and quickstart to reflect it. In quickstart, I changed wicket filter mapping like this: <filter-mapping> <filter-name>wicket.myproject</filter-name> <url-pattern>/wicket/*</url-pattern> </filter-mapping> Now context path is /*, HomePage is not mounted, so application url is http://localhost:8080/wicket . Now I use response.renderCSSReference("css/main.css") as should be. You will see that generated href is css/main.css, wich points to http://localhost:8080/wicket/css/main.css , when it should be ../css/main.css to point to http://localhost:8080/css/main.css , because css path passed to renderCSSReference should be context-relative path, and not wicket-filter-url-pattern relative, isn't it?.
        Hide
        msotil Matteo Sotil added a comment - - edited

        I update quickstart to reflect new conditions required to reproduce the issue.
        Execute Start, go to http://localhost:8080/wicket. If renderCSSReference worked properly, background color should be red (that means css is loaded correctly), but it is not.

        Show
        msotil Matteo Sotil added a comment - - edited I update quickstart to reflect new conditions required to reproduce the issue. Execute Start, go to http://localhost:8080/wicket . If renderCSSReference worked properly, background color should be red (that means css is loaded correctly), but it is not.
        Hide
        pete Peter Ertl added a comment -

        @Matteo: Indeed the current javadoc is wrong. The rendering happens relative to wicket filter root both in current wicket release 1.4.18 and 1.5.0. I sent a mail to the developer mailing list to clarify that issue. Currently the solution will be to properly escape the filter path with '..' to access context relative resources.

        Show
        pete Peter Ertl added a comment - @Matteo: Indeed the current javadoc is wrong. The rendering happens relative to wicket filter root both in current wicket release 1.4.18 and 1.5.0. I sent a mail to the developer mailing list to clarify that issue. Currently the solution will be to properly escape the filter path with '..' to access context relative resources.
        Hide
        pete Peter Ertl added a comment -

        added patch in case we want to fix this...

        Show
        pete Peter Ertl added a comment - added patch in case we want to fix this...
        Hide
        mgrigorov Martin Grigorov added a comment -

        @Igor: do you know what is the expected behavior of this method ?

        Show
        mgrigorov Martin Grigorov added a comment - @Igor: do you know what is the expected behavior of this method ?
        Hide
        ivaynberg Igor Vaynberg added a comment -

        resourcereference urls should be filter relative. raw urls given by the user should be context-relative.

        the patch was bad because it made all urls context-relative - which broke resource refrence urls.

        headerresponse already had a relative() function which shouldve taken care of the conversion but was probably not rewritten correctly when we switched it to use url renderer.

        fixed, thanks for reporting.

        Show
        ivaynberg Igor Vaynberg added a comment - resourcereference urls should be filter relative. raw urls given by the user should be context-relative. the patch was bad because it made all urls context-relative - which broke resource refrence urls. headerresponse already had a relative() function which shouldve taken care of the conversion but was probably not rewritten correctly when we switched it to use url renderer. fixed, thanks for reporting.

          People

          • Assignee:
            ivaynberg Igor Vaynberg
            Reporter:
            msotil Matteo Sotil
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development