Jetty
  1. Jetty
  2. JETTY-173

Jetty 6.0.1 doesnt work with Sitemesh Decorators

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 6.0.1
    • Fix Version/s: 6.0.2, 6.1.0pre1
    • Component/s: JSP
    • Labels:
      None
    • Environment:
      Jetty 6.0.1 Sitemesh 2.2.1 Java 1.5, JSP 2.1, Tomcat 5.5.12
    • Number of attachments :
      3

      Description

      I am currently using Tomcat 5.5.12 and wanted to start using Jetty 6.0.1 but using sitemesh to decorate my pages works great with Tomcat, but with Jetty it doesnt decorate my pages.

        Activity

        Hide
        Jan Bartel added a comment -

        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.

        Show
        Jan Bartel added a comment - 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.
        Hide
        Jan Bartel added a comment -

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

        Show
        Jan Bartel added a comment - Attaching my test webapp which doesn't reproduce the problem, but which perhaps you can modify so that it does.
        Hide
        Kristian Pettersen added a comment -

        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.

        Show
        Kristian Pettersen added a comment - 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.
        Hide
        Kristian Pettersen added a comment -

        Blah + forwarding

        Show
        Kristian Pettersen added a comment - Blah + forwarding
        Hide
        Drew Kutcharian added a comment -

        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

        Show
        Drew Kutcharian added a comment - 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
        Hide
        Drew Kutcharian added a comment -

        see comment above

        Show
        Drew Kutcharian added a comment - see comment above
        Hide
        Tim Vernum added a comment -

        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.

        Show
        Tim Vernum added a comment - 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.
        Hide
        Jan Bartel added a comment -

        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

        Show
        Jan Bartel added a comment - 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
        Hide
        Greg Wilkins added a comment -

        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....

        Show
        Greg Wilkins added a comment - 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....

          People

          • Assignee:
            Jan Bartel
            Reporter:
            arin saghatelian
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: