|
There is a suggested workaround here: http://wiki.opensymphony.com/display/WW/Problem+getting+SiteMesh+to+work+with+web.xml+errorPage
Has been committed. People using sitemesh will need to test their error pages to ensure that any workarounds still work.
Having this problem with cvs as of 2007.02.14 under Jetty 6.1.2pre1
We have the same problem in Grails (http://grails.org) however neither of the proposed solutions work. When debugging it seems that PageResponseWrapper sets sitemesh to abort when sendError is called on the response. This results in sitemesh never applying a layout.
I'm testing on Jetty 6. Any ideas? is there a release date proposed for 2.4 ? We're hitting this issue on tomcat6 and the proposed workaround from the wiki linked above doesn't work.
Darren,
Can you check out HEAD, and let me know if it solves your problem? http://www.opensymphony.com/sitemesh/cvs.action Cheers, Scott Hi Scott,
I get the same behaviour as I do in 2.3. With a 404 response code and the following web.xml stanzas, the page remains undecorated: <filter> <filter-name>sitemesh</filter-name> <filter-class>com.opensymphony.module.sitemesh.filter.PageFilter</filter-class> </filter> ... <filter-mapping> <filter-name>sitemesh</filter-name> <url-pattern>/*</url-pattern> <dispatcher>REQUEST</dispatcher> <dispatcher>FORWARD</dispatcher> <dispatcher>ERROR</dispatcher> </filter-mapping> ... <error-page> <error-code>404</error-code> <location>/WEB-INF/jsp/404.jsp</location> </error-page> Cheers, Darren Darren,
Can you attach a very simple war file that demonstrates your problem? That would make me sure that any solution I work on fixes your specific problem. Scott, attached is a .war that exhibits the same problem as I see in our project when running on Tomcat 6.0.14.
Cheers, just for completeness, my environment is:
OS: Linux 2.6.24 JDK: BEA jrockit-R27.4.0 SERVER: Tomcat 6..0.14 LIB: Sitemesh 2.4 SNAPSHOT compiled from CVS HEAD on 4/May/08 I haven't yet tested this myself - reopening the issue.
any news on this - even just to confirm as an issue to be resolved?
Haven't managed to confirm anything - just re-opened so that I'll look into it.
Does anyone know when 2.4 is going to be released into the maven repositories? We need this fix as well
Jyrate,
I'm afraid I haven't had time to review or commit any changes. I will review any patches you submit (along with testcases) that fix this bug. Has there been a resolution to this? I'm using 2.4.1 and unable to get a 404 page decorated.
This issue kept reproducing for me with Jetty 7 and Sitemesh 2.4.2.
I have checked out the code and made a patch to com.opensymphony.sitemesh.webapp.SiteMeshFilter. I think the problem was that the "filter applied" attribute in the session is set too eagerly, before the filter gets actually applied. I created a patch with my changes (but looks like I can't attach), so I'll paste it here. Index: SiteMeshFilter.java =================================================================== RCS file: /cvs/sitemesh/src/java/com/opensymphony/sitemesh/webapp/SiteMeshFilter.java,v retrieving revision 1.3 diff -u -r1.3 SiteMeshFilter.java --- SiteMeshFilter.java 8 Jan 2007 04:23:03 -0000 1.3 +++ SiteMeshFilter.java 11 Nov 2009 12:30:25 -0000 @@ -83,6 +83,7 @@ Decorator decorator = decoratorSelector.selectDecorator(content, webAppContext); decorator.render(content, webAppContext); + markFilterAppliedForRequest(request); } catch (IllegalStateException e) { // Some containers (such as WebLogic) throw an IllegalStateException when an error page is served. // It may be ok to ignore this. However, for safety it is propegated if possible. @@ -137,13 +138,14 @@ return contentBufferingResponse.getContent(); } - private boolean filterAlreadyAppliedForRequest(HttpServletRequest request) { - if (request.getAttribute(ALREADY_APPLIED_KEY) == Boolean.TRUE) { - return true; - } else { - request.setAttribute(ALREADY_APPLIED_KEY, Boolean.TRUE); - return false; - } + private boolean filterAlreadyAppliedForRequest( + final HttpServletRequest request) { + return (request.getAttribute(ALREADY_APPLIED_KEY) == Boolean.TRUE); + } + + private void markFilterAppliedForRequest( + final HttpServletRequest request) { + request.setAttribute(ALREADY_APPLIED_KEY, Boolean.TRUE); } } Just so you know - that patch won't work. Because it is recursive, you have to set the property before you apply the filter.
I'm not sure what the bug is, but your patch will definitely break in certain cases, and on certain application servers. I suspected something on this direction.
The thing is that at least Jetty does not throw a ServletException when it encounters 40x and 50x errors, instead returns the page configured on the web.xml <error-page> or the default ugly page if there is no error-page defined. I don't know if that behaviour breaks the spec or not, but in that case the filter won't be applied and it should. Knowing that, maybe a solution is to always obtainContent and only decorate if the ALREADY_APPLIED_KEY is not set, (then only the innermost sitemesh filter would decorate, but I don't know is that is the intended behavior). Forget my last comment.
Due to its nature, the sitemesh filter should be applied to already generated contents (at the recursion return), so if it is to be applied once, it must be on the innermost instance only. This is why putting the mark before the filter does not work. Specific container exceptions aside, I think the correct flow would be to always obtainContent, then check if the filter has to apply, if so decorate, then set the mark. This is assuming servlet >= 2.4 and the filter has the dispatchers <dispatcher>FORWARD</dispatcher> <dispatcher>REQUEST</dispatcher> <dispatcher>ERROR</dispatcher> |
||||||||||||||||||||||||||||||||||||
 |
|
Bug
Reopened
error pages aren't decorated with Tomcat 5
The funny thing is that my 403 page _does_ get decorated, while my 404 and 500 pages do not.