Wicket
  1. Wicket
  2. WICKET-1307

autolinked resources have locale appended

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.3.0-final, 1.3.1
    • Fix Version/s: 1.3.2
    • Component/s: wicket
    • Labels:
      None

      Description

      For a resource that does not have a locale-specific file, it should be appended to the resource key. This works correctly for the first request to a page with the autolinked resource; you get a file name that matches the one in the sources. But on all following requests a locale (like _en_US) will be inserted into the name. While the resource can be served (because it's been added to the shared resource pool) this name has a significant downside. It can not be resolved in reverse. Therefore, if the server is restarted and a client already knows of that resource location including the _en_US and requests it before requesting the page that auto-link it, a 404 such as this is returned:

      Unable to find package resource [path = ts4/web/wicket/component/FeedbackPanel_en_US.css, style = null, locale = null]

      Futhermore, all future requests will fail, even after the page with the component has rendered, because the bad resource specifier has been added to the pool.

      The reason for this behavior is complicated, but it comes down to this static method:

      PackageResource.get(final Class scope, final String path, final Locale locale, final String style)

      Not only goes it "get" the resource, it adds it to the resource pool. The autolinker, in the course of finding the right resource (with a locale matching actual file names) inadvertently adds the wrong resource by trying to get it as a test. It discovers the right resource and serves it with that name on the first request, but following that it is able to find the resource in the pool with the wrong name and so serves it in that manner.

      1. resource.patch
        0.5 kB
        Nathan Hamblen

        Activity

        Hide
        Nathan Hamblen added a comment -

        This patch removes the line that adds the shared resource in the get() function. I can't guarantee that it doesn't break anything that depends upon get() also doing the add. In applying it I confirmed that it does solve the problem and does not have any apparent side effects in the t.s. codebase.

        Show
        Nathan Hamblen added a comment - This patch removes the line that adds the shared resource in the get() function. I can't guarantee that it doesn't break anything that depends upon get() also doing the add. In applying it I confirmed that it does solve the problem and does not have any apparent side effects in the t.s. codebase.
        Hide
        Johan Compagner added a comment -

        it did break one thing.
        PackageResourceTest ...

        Now PackageResource.bind() doesn't really bind anymore..

        Show
        Johan Compagner added a comment - it did break one thing. PackageResourceTest ... Now PackageResource.bind() doesn't really bind anymore..
        Hide
        Johan Compagner added a comment -

        i added the add line again but now in the bind method itself and not in get

        Show
        Johan Compagner added a comment - i added the add line again but now in the bind method itself and not in get
        Hide
        Eelco Hillenius added a comment -

        Sorry about that. And thanks for fixing it.

        Show
        Eelco Hillenius added a comment - Sorry about that. And thanks for fixing it.
        Hide
        Nathan Hamblen added a comment -

        1.3.3 is doing this again, anyone know what happened?

        Show
        Nathan Hamblen added a comment - 1.3.3 is doing this again, anyone know what happened?
        Hide
        Juergen Donnerstag added a comment -

        please provide a junit test case with the correct assertion. Only than you can be sure that the functionality doesn't change.

        Show
        Juergen Donnerstag added a comment - please provide a junit test case with the correct assertion. Only than you can be sure that the functionality doesn't change.
        Hide
        Nathan Hamblen added a comment -

        The procedure needed to reveal this bug is bit elaborate for a unit test (it requires multiple requests, and the markup itself is the only sure place to validate). For now I will concentrate on debugging it and supplying a new patch.

        Show
        Nathan Hamblen added a comment - The procedure needed to reveal this bug is bit elaborate for a unit test (it requires multiple requests, and the markup itself is the only sure place to validate). For now I will concentrate on debugging it and supplying a new patch.
        Hide
        Nathan Hamblen added a comment -

        Okay I found the problem. It's different enough from the way this one was originally observed and triggered that I created a new bug, WICKET-1556. This one may be closed again.

        Show
        Nathan Hamblen added a comment - Okay I found the problem. It's different enough from the way this one was originally observed and triggered that I created a new bug, WICKET-1556 . This one may be closed again.
        Hide
        Frank Bille Jensen added a comment -

        Closed by demand

        Show
        Frank Bille Jensen added a comment - Closed by demand

          People

          • Assignee:
            Unassigned
            Reporter:
            Nathan Hamblen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development