[ https://issues.apache.org/jira/browse/WICKET-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565059#action_12565059 ]
Johan Compagner commented on WICKET-1307: ----------------------------------------- i added the add line again but now in the bind method itself and not in get > autolinked resources have locale appended > ----------------------------------------- > > Key: WICKET-1307 > URL: https://issues.apache.org/jira/browse/WICKET-1307 > Project: Wicket > Issue Type: Bug > Components: wicket > Affects Versions: 1.3.0-final, 1.3.1 > Reporter: Nathan Hamblen > Priority: Minor > Fix For: 1.3.2 > > Attachments: resource.patch > > > 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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.