Using web.xml <error-page> to render error pages via Wicket yields undesired 
behavior in Wicket 1.5
---------------------------------------------------------------------------------------------------

                 Key: WICKET-3551
                 URL: https://issues.apache.org/jira/browse/WICKET-3551
             Project: Wicket
          Issue Type: Bug
          Components: wicket-core
    Affects Versions: 1.5-RC2
            Reporter: Matt Brictson


In my applications I prefer to use Wicket to render all error pages, including 
my 404 "not found" page. This allows me to reuse a shared page template 
afforded by Wicket to create my error pages (i.e. by extending a BasePage), 
rather than using copy and paste to maintain static error page HTML files.

I have been doing this as follows:

web.xml:

 <error-page>
   <error-code>404</error-code>
   <location>/error/404</location>
 </error-page>

Now, so long as I have an appropriate bookmarkable page mounted on the 
"/error/404" path, the servlet container will render my page whenever a 404 
"not found" scenario is encountered.

This works great in Wicket 1.4.x.

However in Wicket 1.5 (RC2 and the latest SNAPSHOT as of this writing), two 
problems occur:

1. By default, Wicket 1.5 automatically performs a 302 redirect before 
rendering the error page. This changes the URL from the invalid one (i.e. the 
one that generated the 404) to the mounted path (/error/404 in this example). 
This is not the desired behavior for a 404 error page; the original URL 
requested by the user should be maintained.

2. If I attempt to work around the issue by overriding 
WebPageRenderer.enableRedirectForStatelessPage() to return false, the problem 
gets worse. Now the URL doesn't change, which is good. But Wicket gets confused 
about the depth of the request URL path: it seems to calculate relative URLs 
based on the mounted path rather than the URL that was requested. This causes 
all relative resources on the page (e.g. stylesheet references) to be 
miscalculated and break.

I will attach two quickstarts: one showing this configuration working in 1.4, 
and another showing the same setup failing as described above in 1.5-RC2.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to