[
https://issues.apache.org/jira/browse/WICKET-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095487#comment-13095487
]
Bertrand Guay-Paquet edited comment on WICKET-3602 at 9/1/11 6:25 PM:
----------------------------------------------------------------------
edit: the following only works for base urls at the root of the servlet.
Here is a workaround I am now using. Add the following to your sub-class of
RequestCycle (works in 1.5-RC7):
@Override
protected UrlRenderer newUrlRenderer() {
UrlRenderer urlRenderer = super.newUrlRenderer();
Object request = getRequest().getContainerRequest();
if (request instanceof HttpServletRequest) {
HttpServletRequest httpRequest = (HttpServletRequest)
request;
Integer code = (Integer)
httpRequest.getAttribute("javax.servlet.error.status_code");
// If the request is for an error-page, use the request
URL as the base URL.
// This avoids having wrong relative URLs for error
page resources.
if (code != null) {
Url newBaseUrl = getRequest().getUrl();
urlRenderer.setBaseUrl(newBaseUrl);
}
}
return urlRenderer;
}
With this code, I get proper relative resource URLs. Are there any cases where
this would not work? If not, could this form the basis of a simple fix of this
issue without requiring the big rework mentioned by Igor? (at least for 1.5)
Note:
While investigating the same problem, I found this issue. To make the
quickstart run, I had to modify pom.xml by removing the following lines :
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
</dependency>
For some reason, this caused me a dependency problem with jmx...
was (Author: berniegp):
Here is a workaround I am now using. Add the following to your sub-class of
RequestCycle (works in 1.5-RC7):
@Override
protected UrlRenderer newUrlRenderer() {
UrlRenderer urlRenderer = super.newUrlRenderer();
Object request = getRequest().getContainerRequest();
if (request instanceof HttpServletRequest) {
HttpServletRequest httpRequest = (HttpServletRequest)
request;
Integer code = (Integer)
httpRequest.getAttribute("javax.servlet.error.status_code");
// If the request is for an error-page, use the request
URL as the base URL.
// This avoids having wrong relative URLs for error
page resources.
if (code != null) {
Url newBaseUrl = getRequest().getUrl();
urlRenderer.setBaseUrl(newBaseUrl);
}
}
return urlRenderer;
}
With this code, I get proper relative resource URLs. Are there any cases where
this would not work? If not, could this form the basis of a simple fix of this
issue without requiring the big rework mentioned by Igor? (at least for 1.5)
Note:
While investigating the same problem, I found this issue. To make the
quickstart run, I had to modify pom.xml by removing the following lines :
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.15</version>
</dependency>
For some reason, this caused me a dependency problem with jmx...
> Wrong relative URLs in an error page during error dispatching when using
> non-empty context path or wicket filter prefix
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WICKET-3602
> URL: https://issues.apache.org/jira/browse/WICKET-3602
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 1.5-RC3
> Environment: Tomcat 5
> Reporter: Sergiy Barlabanov
> Assignee: Igor Vaynberg
> Priority: Minor
> Fix For: 1.6.0
>
> Attachments: wicket-errorpage.zip
>
>
> since 1.5-RC3 the rendering of error pages does not work properly. All
> relative URLs inside a page are incorrect.
> Sample scenario:
> - create an error page
> - mount it in the Application class
> - define <error-page> in the web.xml pointing to the error page
> - start the application using some non-empty context path (or configure a
> filterPrefix - something like /blabla/* instead of /* in the web.xml)
> - navigate to a non existing page
> Expected:
> the error page must be shown with JavaScript and CSS resources loaded
> correctly and links containing correct relative urls.
> Result:
> the error page is shown, but none of the resources are loaded (404), links
> and buttons does not work
> This problem was already there in 1.4.x (WICKET-2712) and it was fixed. With
> the latest changes in ServletWebRequest class, the problem occurs again.
> According to the source code, the error page handling was extended in 1.5-RC3
> to preserve a client URL (shouldPreserveClientUrl method in ServletWebRequest
> class). The intention of the change is ok, since before that, a redirect was
> made and the user did no see his/her wrong URL in the browser address bar.
> But the implementation seems to be inconsistent, since all URLs are resolved
> against the client URL from the request (ErrorAttributes#getRequestUri) and
> this url is wrong and non-existing and resource can be resolved against it.
> The method "getClientUrl" in ServletWebRequest returns the original error URL
> obtained from the forward request. And UrlRenderer uses it as its baseUrl,
> which is wrong, since this URL is not a Wicket Filter URL and
> UrlRenderer#renderRelativeUrl returns incorrect relative URLs for that.
> The patch would be either to make UrlRenderer#renderRelativeUrl work not only
> with Wicket Filter urls (which is quite complex I assume) or to correct
> ServletWebRequest#getClientUrl to return the URL of the error page
> (ServletWebRequest#getUrl(httpServletRequest, filterPrefix)) relativized to
> the original error URL from the forward request
> (ErrorAttributes#getRequestUri).
> There is an attachment with the quickstart application:
> WicketFilter is configured with the URL mapping /ui/*. Go to the home page
> and follow "Go to a non existing page" link. The error page is going to be
> shown. If everything works, the background of the body must be red and the
> link "Go to HomePage" must proceed again to the home page.
> My intention was to fix ServletWebRequest#getClientUrl. If it's ok, I will
> try to provide a patch.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
