Wicket
  1. Wicket
  2. WICKET-1205

Relative path calculations for inline paths in non-bookmarkable pages are incorrect on Tomcat.

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.3.0-rc1
    • Fix Version/s: 1.3.5
    • Component/s: wicket
    • Labels:
      None
    • Environment:
      JBoss 4.2 / Tomcat Embedded

      Description

      When linking from a bookmarked page to a non-bookmarked page the relative link to the CSS page breaks.

      1. CSSIssueQuickStart.tar.gz
        12 kB
        Jeremy Levy
      2. WICKET-1205.zip
        9 kB
        Alastair Maw
      3. OldUrlFilter.java
        1 kB
        Scott Sauyet

        Issue Links

          Activity

          Hide
          Jeremy Levy added a comment -

          See attached quickstart project (as netbeans 5.5.1 project) for example.

          Show
          Jeremy Levy added a comment - See attached quickstart project (as netbeans 5.5.1 project) for example.
          Hide
          Jeremy Levy added a comment -

          Adding comments from: Oliver Lieven

          Hi, I encountered this problem a week ago, too, and digged a little into code
          and forum. Here's my summary:

          the problem seems to be the "/" filter mapping. If you specify a "/app/"
          filter mapping, relative URLs work just fine.

          In my base-page-class (all my pages are derived from it through Wicket's
          great markup inheritance) my stylesheet is referenced in the head-section
          by a relative reference like

          <link rel="stylesheet" type="text/css" href="style/myapp.css" />

          Checking the generated HTML in the browser (when using "/*" filter mapping)
          shows that this reference is modified by Wicket, so that it now reads

          <link rel="stylesheet" type="text/css" href="../style/myapp.css" />

          This is an invalid path and addresses a wrong location.

          I digged into the code and found that relative stylesheet and image
          references where
          automatically prepended by "../" by
          ServletWebRequest.getRelativePathPrefixToContextRoot().

          This seems to work well for the "/app/" filter mapping, but fails for "/"
          (since theres no parent-directory in between to skip)

          I currently decided to use the "/app/*" filter mapping.

          Following workarounds came into my mind:

          1. use of "absolute" references like "/myapp/style/myapp.css".
          pro: works, Wicket doesn't modify the absolute paths
          cons: must code the context-path into all style and image references,
          which is a "NO GO"

          2. use of "/app/*" filter mapping
          pro : works
          cons: after having seen the much nicer "/*" mapping I want to use it )

          3. in HTML it is possible to add a <base
          href="http://localhost:8080/myapp/"/>
          line into the head section, which is used to resolve all relative
          references
          pro : would be great, since it allows the use of relative URLs, and it
          must
          be configured in just one place (the base-page's head section)
          would also be great to use when using a front end server (Apache),
          since references would be resolved to root context
          cons: since Wicket isn't aware of the <base> tag, relative references
          are still modified and prepended by "../", so no stylesheets/images
          were found

          4. fix it )

          Related threads and infos:

          -
          http://cwiki.apache.org/WICKET/best-practices-and-gotchas.html#BestPracticesandGotchas-WicketServletMapping

          Show
          Jeremy Levy added a comment - Adding comments from: Oliver Lieven Hi, I encountered this problem a week ago, too, and digged a little into code and forum. Here's my summary: the problem seems to be the "/ " filter mapping. If you specify a "/app/ " filter mapping, relative URLs work just fine. In my base-page-class (all my pages are derived from it through Wicket's great markup inheritance) my stylesheet is referenced in the head-section by a relative reference like <link rel="stylesheet" type="text/css" href="style/myapp.css" /> Checking the generated HTML in the browser (when using "/*" filter mapping) shows that this reference is modified by Wicket, so that it now reads <link rel="stylesheet" type="text/css" href="../style/myapp.css" /> This is an invalid path and addresses a wrong location. I digged into the code and found that relative stylesheet and image references where automatically prepended by "../" by ServletWebRequest.getRelativePathPrefixToContextRoot(). This seems to work well for the "/app/ " filter mapping, but fails for "/ " (since theres no parent-directory in between to skip) I currently decided to use the "/app/*" filter mapping. Following workarounds came into my mind: 1. use of "absolute" references like "/myapp/style/myapp.css". pro: works, Wicket doesn't modify the absolute paths cons: must code the context-path into all style and image references, which is a "NO GO" 2. use of "/app/*" filter mapping pro : works cons: after having seen the much nicer "/*" mapping I want to use it ) 3. in HTML it is possible to add a <base href="http://localhost:8080/myapp/"/> line into the head section, which is used to resolve all relative references pro : would be great, since it allows the use of relative URLs, and it must be configured in just one place (the base-page's head section) would also be great to use when using a front end server (Apache), since references would be resolved to root context cons: since Wicket isn't aware of the <base> tag, relative references are still modified and prepended by "../", so no stylesheets/images were found 4. fix it ) Related threads and infos: "is it a bug" - use of /* filter mapping - http://www.nabble.com/is-it-a-bug--%28using-beta-4%29-tf4649929.html#a13284326 "Wicket behind a frontend proxy" - http://www.nabble.com/Wicket-behind-a-front-end-proxy-t4776982.html - http://cwiki.apache.org/WICKET/best-practices-and-gotchas.html#BestPracticesandGotchas-WicketServletMapping
          Hide
          Alastair Maw added a comment -

          I've downloaded your quickstart (which isn't really a quickstart at all, but I digress...)

          I've added a StartJetty to it so I can actually run it. It works just fine, whether I add a context path or not, as expected.

          Looks like this might be a Tomcat-specific bug. Am off to investigate further...

          Show
          Alastair Maw added a comment - I've downloaded your quickstart (which isn't really a quickstart at all, but I digress...) I've added a StartJetty to it so I can actually run it. It works just fine, whether I add a context path or not, as expected. Looks like this might be a Tomcat-specific bug. Am off to investigate further...
          Hide
          Alastair Maw added a comment -

          On the bundled 5.5.17 Tomcat that comes with Netbeans, deploying the WAR file built by your ant build script fails due to missing log4j and slf4j JARs. If you add these into Tomcat's common/lib folder, the WAR will deploy properly.

          I can confirm that I can reproduce this under that environment. Guess I need to get Tomcat going under Eclipse and work out what's going on...

          So yes, this is indeed Tomcat-specific. Needs fixing before 1.3.0 final or lots of people will be cross.

          (Note to self - crypted/un-crypted URLs makes no difference.)

          Show
          Alastair Maw added a comment - On the bundled 5.5.17 Tomcat that comes with Netbeans, deploying the WAR file built by your ant build script fails due to missing log4j and slf4j JARs. If you add these into Tomcat's common/lib folder, the WAR will deploy properly. I can confirm that I can reproduce this under that environment. Guess I need to get Tomcat going under Eclipse and work out what's going on... So yes, this is indeed Tomcat-specific. Needs fixing before 1.3.0 final or lots of people will be cross. (Note to self - crypted/un-crypted URLs makes no difference.)
          Hide
          Jeremy Levy added a comment -

          I am using Tomcat 5.5 embeded in JBoss:

          Servlet 2.4; JBoss-4.2.1.GA (build: SVNTag=JBoss_4_2_1_GA date=200707131605)/Tomcat-5.5

          Show
          Jeremy Levy added a comment - I am using Tomcat 5.5 embeded in JBoss: Servlet 2.4; JBoss-4.2.1.GA (build: SVNTag=JBoss_4_2_1_GA date=200707131605)/Tomcat-5.5
          Hide
          Gabor Szokoli added a comment -

          We experience the same problem (and work around it with a /app/ mapping) under Glassfish V2. (I'm not 100% up to date on how far its servlet container has diverged from tomcat.)

          Show
          Gabor Szokoli added a comment - We experience the same problem (and work around it with a /app/ mapping) under Glassfish V2. (I'm not 100% up to date on how far its servlet container has diverged from tomcat.)
          Hide
          Vincent van 't Zand added a comment -

          We are planning to deploy our Wicket app on Tomcat, because that's our time-proven standard. Not sure how big the impact of this bug will be, because we just started experimenting with Wicket and are still not sure what content is going to be on our Home page. For now the only path we use in Home is for CSS. I use this workaround:

          <style type="text/css">
          @import "style.css";
          </style>

          Sure hope there will be a fix soon, because this special case for Home is too error-prone and seems to cause other problems with Tomcat: in order to get the 'authtest' example to work, I have to remove the 'index.html' file from the 'Webapp' directory?!?

          This is with Tomcat 5.5.25 running under Eclipse 3.3.1.1 on Mac OS 10.4.11.

          Show
          Vincent van 't Zand added a comment - We are planning to deploy our Wicket app on Tomcat, because that's our time-proven standard. Not sure how big the impact of this bug will be, because we just started experimenting with Wicket and are still not sure what content is going to be on our Home page. For now the only path we use in Home is for CSS. I use this workaround: <style type="text/css"> @import "style.css"; </style> Sure hope there will be a fix soon, because this special case for Home is too error-prone and seems to cause other problems with Tomcat: in order to get the 'authtest' example to work, I have to remove the 'index.html' file from the 'Webapp' directory?!? This is with Tomcat 5.5.25 running under Eclipse 3.3.1.1 on Mac OS 10.4.11.
          Hide
          Alastair Maw added a comment -

          Yep. I'm going to look into fixing this this week if at all possible.

          Show
          Alastair Maw added a comment - Yep. I'm going to look into fixing this this week if at all possible.
          Hide
          Alastair Maw added a comment -

          I've tried everything, but I can't reproduce this at all.

          Apache Tomcat versions:
          5.5.17
          5.5.26
          6.0.14
          6.0.16

          Wicket versions:
          1.3.0-rc1
          1.3.0
          1.3.2

          I've tried with Tomcat standalone, with a test app deployed as a WAR, and with Tomcat embedded in in a StartTomcat class. I've tried with a root context and a context path of "/foo". I just can't reproduce this. I'm attaching a quickstart project to demonstrate what works.

          If anyone can give me a quickstart project ZIP that I can create a WAR from that lets me reproduce this issue, then I will be very glad to fix it for you, but I just can't see how to reproduce this at the moment.

          Show
          Alastair Maw added a comment - I've tried everything, but I can't reproduce this at all. Apache Tomcat versions: 5.5.17 5.5.26 6.0.14 6.0.16 Wicket versions: 1.3.0-rc1 1.3.0 1.3.2 I've tried with Tomcat standalone, with a test app deployed as a WAR, and with Tomcat embedded in in a StartTomcat class. I've tried with a root context and a context path of "/foo". I just can't reproduce this. I'm attaching a quickstart project to demonstrate what works. If anyone can give me a quickstart project ZIP that I can create a WAR from that lets me reproduce this issue, then I will be very glad to fix it for you, but I just can't see how to reproduce this at the moment.
          Hide
          Alastair Maw added a comment -

          Quickstart to demonstrate that I can't reproduce this.

          Show
          Alastair Maw added a comment - Quickstart to demonstrate that I can't reproduce this.
          Hide
          Alastair Maw added a comment -

          Gah! I've finally figured out what triggers this - it's the presence of an index.html/index.jsp file in your context root. If you remove that, things will work as you expect. Tomcat does something odd here that it shouldn't. I'm off to see if I can figure out a workaround for it.

          Show
          Alastair Maw added a comment - Gah! I've finally figured out what triggers this - it's the presence of an index.html/index.jsp file in your context root. If you remove that, things will work as you expect. Tomcat does something odd here that it shouldn't. I'm off to see if I can figure out a workaround for it.
          Hide
          Scott Sauyet added a comment - - edited

          One possible work-around for those like me who need the URL that includes index.jsp but not the actual file, is to add a servlet filter which simply redirects to the main application. A more involved version of the attached OldUrlFilter.java allows old bookmarks to easily map to newer version.

          There is more discussion of this at http://tinyurl.com/3gcbsa

          Show
          Scott Sauyet added a comment - - edited One possible work-around for those like me who need the URL that includes index.jsp but not the actual file, is to add a servlet filter which simply redirects to the main application. A more involved version of the attached OldUrlFilter.java allows old bookmarks to easily map to newer version. There is more discussion of this at http://tinyurl.com/3gcbsa
          Hide
          Igor Vaynberg added a comment -

          this is quiet esoteric and we should not be fixing tomcat weirdness

          Show
          Igor Vaynberg added a comment - this is quiet esoteric and we should not be fixing tomcat weirdness
          Hide
          Antony Stubbs added a comment -

          has anyone got any links to any information / issues on the tomcat side of things? I'd like to follow the trail further....

          Show
          Antony Stubbs added a comment - has anyone got any links to any information / issues on the tomcat side of things? I'd like to follow the trail further....

            People

            • Assignee:
              Alastair Maw
              Reporter:
              Jeremy Levy
            • Votes:
              4 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development