Jetty 6.0.1 doesnt work with Sitemesh Decorators

Arin,

I'm guessing you and Drew Kutcharian are reporting the same problem. If so, I've responded on the jetty lists. Here's what I said:

—
I haven't been able to reproduce the problem using jetty 6.1 nor jetty 6.0.1.

I've made a tiny sitemesh webapp using the maven sitemesh webapp archetype
we made available on the webtide website here: http://www.webtide.com/resources.jsp

I changed it so that:

• I have a /index.jsp and another one in /floople/index.jsp.
• decorators.xml only decorates /floople/*
• moved /decorators/main.jsp into WEB-INF

I've run it with mvn jetty:run with recent 6.1-SNAPSHOT of jetty, a recent
6.0-SNAPSHOT and the 6.0.1 release of jetty and it works just fine
under all of them.

I'll try and attach it to this email, but I don't know if the list
accepts attachments. If not, it is a couple of seconds work to
download the archetype, generate a webapp and modify it. You
run it with mvn jetty:run.

If you can modify the archetype generated webapp so it fails in
the same way as yours, then please open a Jira issue
(http://jira.codehaus.org/browse/Jetty) for it, attach the webapp
and we'll take another look.
—

As you've already got this issue open, attach any test webapp to it rather than open a new issue.

Attaching my test webapp which doesn't reproduce the problem, but which perhaps you can modify so that it does.

We are experiencing the same problem running sitemesh and jetty.

Some of our pages are working and others are not. After a little investigating we found that when we are using a spring view that forwards to a jsp it doesnt work. While in the views that doesnt do a forward sitemesh decorates the page as expected.

We been running resin until now and everything works fine there.

I'll upload a modifed version of your webapp where ive added /floople/forward.jsp that does a forward to /floople/index.jsp.
If i invoke /floople/forward.jsp : not decorated
if I invoke /floople/index.jsp : decorated

If i run the app in resin both gets decorated.

Blah + forwarding

Jan,

I created a sample WAR that prodcues the issue. I think this might be related to the "forward" issue above. Since SiteMesh doesn't work when using WebWork actions (which dispatch the request to JSPs).

I have included two decorators.xml, one that works, but applies the same decorator to all the URL patterns (decorators.xml.working) and one that I'd like to get it to work (decorators.xml).

I love Jetty and I hate not being able to use it because of this issue

I am going to attach "mytest.war" to this issue.

Thanks again for all the help.

Drew

see comment above

I've tracked it down a bit.
It appears that "getServletPath()" is returning blank when filtering the forward.
I need to dig a bit deeper, but what I have so far is:

When hitting a jsp directly I get:
PathInfo : null
ServletPath: /decorate/index.jsp
RequestURI: /sitemesh/decorate/index.jsp
RequestURL: http://localhost:8080/sitemesh/decorate/index.jsp

When forwarding to it I get:
PathInfo : /decorate/index.jsp
ServletPath:
RequestURI: /sitemesh/forward/index.jsp
RequestURL: http://localhost:8080/sitemesh/forward/index.jsp

Which isn't what SiteMesh is expecting.
There's definately something strange going on with the PathInfo/ServletPath decoding inside a forward.

Tim,

same here.

Interestingly, if you use sitemesh 2.3 it works. They have several comments in their checkins for sitemesh2.3 about improving handling of getServletPath() which returns "" for servlet 2.5 containers.

Have a look at:
http://fisheye5.cenqua.com/browse/sitemesh/src/java/com/opensymphony/module/sitemesh/mapper/ConfigDecoratorMapper.java?r=1.2

around line 50, it is testing the servletPath to find a decorator to apply. See the comment at line 63, which is on the new code in sitemesh2.3 to handle "" instead of null for the getServletPath(). Interestingly, the comment says servlet2.4 containers return "" for getServletPath() matching /*, but in fact it is servlet2.5 containers.

I'll double check with Greg on this.

regards
Jan

Oh - my bad!

I was not restoring the value of servlet path AFTER a dispatch.
Because sitemesh does its matching after the filter chain, it was working on crappy data!

Fixed in trunk and 6.0 branch..... releases kind of soon ish....