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.

Scott Sauyet
added a comment - 06/May/08 15:04 - 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

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.

Alastair Maw
added a comment - 01/Apr/08 02:37 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.

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.

Alastair Maw
added a comment - 01/Apr/08 00:40 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.

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.

Vincent van 't Zand
added a comment - 09/Mar/08 22:38 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.

Gabor Szokoli
added a comment - 09/Dec/07 20:40 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.)

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.

Alastair Maw
added a comment - 07/Dec/07 08:53 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.)

Alastair Maw
added a comment - 07/Dec/07 08:18 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...

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

Jeremy Levy
added a comment - 04/Dec/07 17:56 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