Andy Nelsen » Java http://www.andynelsen.com Just another WordPress weblog Thu, 19 Nov 2009 19:59:41 +0000 http://wordpress.org/?v=2.8.6 en hourly 1 Hack Alert: Decorate 404 and other HTTP error pages with Sitemesh/Stripes http://www.andynelsen.com/2009/11/10/hack-alert-decorate-404-and-other-http-error-pages-with-sitemeshstripes/ http://www.andynelsen.com/2009/11/10/hack-alert-decorate-404-and-other-http-error-pages-with-sitemeshstripes/#comments Tue, 10 Nov 2009 17:27:13 +0000 Andy http://www.andynelsen.com/?p=6 Dang. Second post and I’m already resorting to workarounds. This problem is particularly maddening, though, so any of you who have arrived at this page are probably at the point where you just want to make this work. Read on.

Lots of people have had problem getting Sitemesh to decorate error pages in their applications. You can create a custom error page and put content in it, but no matter what you do, you can’t get the boilerplate design decorations to render and you end up with a blank page with no head content and just the unstyled content you have put in the jsp.

I’ve seen people come across this error and it is not entirely clear who the culprit is in the stack. My config uses Stripes as the front controller, Sitemesh as the template/decoration engine, and everything is running on Jetty.

This is in the web.xml:

  1. <filter-mapping>
  2.     <filter-name>StripesFilter</filter-name>
  3.     <url-pattern>*.jsp</url-pattern>
  4.     <dispatcher>REQUEST</dispatcher>
  5.     <dispatcher>ERROR</dispatcher>
  6. </filter-mapping>
  7.  
  8. <filter-mapping>
  9.     <filter-name>sitemesh</filter-name>
  10.     <url-pattern>/*</url-pattern>
  11. </filter-mapping>
  12. …
  13. <error-page>
  14.     <error-code>404</error-code>
  15.     <location>/not-found.jsp</location>
  16. </error-page>

…and the actual error page… (irrelevant layout markup removed)

  1. <%@include file="/WEB-INF/jsp/include/page_header.jspf" %>
  2. <html xmlns="http://www.w3.org/1999/xhtml">
  3. <head>
  4.     <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  5.     <title>Title Meh</title>
  6.     <link rel="stylesheet" href="/library/css/screen.css" type="text/css" media="screen, projection" />
  7. </head>
  8. <body>
  9.     <h1>Oops!</h1>
  10.     <p>The page you are looking for was not found.</p>
  11. </body>
  12. </html>

The problem seems to be that HTTP errors get routed around the decorator you have selected, even if you explicitly set a decorator for the page in decorators.xml. Instead, the unstyled error page is displayed raw. I’ve heard people say that the problem is a bug in Sitemesh and that it is fixed in newer versions, but even upgrading to 2.4.x does not solve the problem automatically. I’ve also heard people say that the problem is a Jetty bug, but I’m not sure about that because I’ve seen people complain of the same problem using Tomcat.

After a couple hours of wading through usergroups I have decided not to solve the problem but to bypass it in the name of getting something done for the day…

The (Temporary) Solution
This workaround is intended only as a stopgap only. It is not ultimately an acceptable solution as the stack should be handling this situation itself, but when the boss just wants to see rounded corners on the error page, here is what to do:

Add the following to the top of your not-found.jsp page above the Doctype declaration:

  1. <%
  2.     if (request.getParameter("show") == null) {
  3.         response.sendRedirect("not-found.jsp?show=true");
  4.         return;
  5.     }
  6. %>

When the page loads without the “show” parameter present, it will redirect back to itself. This has the effect of triggering a normal routing event that is then picked up by Sitemesh and decorated like all other normal requests. The page will reload and … win! Your page will be styled as expected and wrapped in whatever boilerplate code you have defined in the decorator.

The selection of “show” as the URL param to test for was arbitrary. You can use any parameter you want, as long as it isn’t a parameter used elsewhere in the application.

My hope is that somebody reading this will see what I’ve done wrong and correct me so that we can all benefit from the ultimate solution to the problem, but for those of you who are just desperate to see the expected behavior, this will hopefully make your day a little better!

]]> http://www.andynelsen.com/2009/11/10/hack-alert-decorate-404-and-other-http-error-pages-with-sitemeshstripes/feed/ 1