I'm on a shared hosting account with Tomcat 5.5 and cannot figure out why I can't set the default servlet. I want all incoming requests regardless of the relative path, to be handled by the Redirect servlet. There is only one servlet in the whole project.
With the below web.xml file, the last two above works just fine, but the first two gives a 403 error. What gives, I followed the Tomcat documentation to the teeth... It seems to work on my development server, but not on the shared hosting. Is this a setting anyone would block? Any help would be much appreciated.
The full web.xml setting below:
I tried adding other mappings as well that didn't work, such as :
What would happen if I try an empty url-pattern?
Any help would be much appreciated. I tried workarounds, by using an index.jsp file to supplement, but that isn't working quite right either. I prefer to have it setup properly though.... Please Help!!!
Have you actually replaced the default (root) servlet itself? It's a little trickier than simply updating the webapps/ROOT directory.
An IDE is no substitute for an Intelligent Developer.
siu lung lee
Joined: Apr 28, 2009
Tim Holloway wrote:Have you actually replaced the default (root) servlet itself? It's a little trickier than simply updating the webapps/ROOT directory.
It is not actually setup to be the ROOT application since it is in a shared hosting environment. The default servlet is uploaded fresh frequently and works when accessed through an alternative URL that I setup. It just does not work when accesing it through something like:
It works if you have at least one directory in the URL...
I don't care HOW much a URL looks like a filesystem path. It's not a filesystem path. Just sometimes it will be decoded to form a WAR path that looks like (part of) a filesystem path. And sometimes it won't. A web server is not a file server.
Normally in a J2EE webapp, you define an application context. This context is part of the base URL for the application. For example, http://localhost:8080/admin would route your URL request to the Tomcat administration webapp, if it's installed. Tomcat is designed to hold multiple applications, each one accessed through its own application context.
The ROOT context is what you get if you don't specify a defined context. It's what displays the page with the Tomcat logo on it. But, as I said, it's a bit tricky to replace.
Most people don't bother to. When they want to provide multiple virtual hosts, they front Tomcat with a proxy webserver (most often Apache). The proxy translates a URL such as "http://www.myapp.com/homePage.jsp" to "http://www.myapp.com:8080/myapp/homePage.jsp" and they deploy a "myapp" webapp to serve that request.
So to make a "http://www.mydomain.com" work, you'd redirect the proxy to "http://www.mydomain.com:8080/myapp", and set myapp's hello page to "homePage.jsp" in myapp's web.xml file. You also, of course, have to build and deploy a myapp WAR to Tomcat and tell apache how to proxy the request using an ajp connector or Apache mod_proxy.
Tomcat will handle multiple virtual hosts - no need for a proxy webserver - just a matter of configuring more <Host elements in server.xml
The appBase attribute points to a location that you will treat like the webapps directory in a plain installation. Whatever you put in the ROOT subdirectory of that location becomes the default for that host.
Important note: you must have a Host entry for each variant of the URL - so if you want www.mysite.com and mysite.com to work, thats two Host elements.
I have been running multiple hosts for years with Tomcat 5.5.9.
That was sloppy of me. I've run Tomcat virtual hosts without Apache myself. However, it's still common practice to front Tomcat with Apache, even when serving up a single site.
While Apache is no longer significantly faster for serving static content, it does clean up the URLs a little. Nothing Tomcat CAN'T do, but since it's common for there to be an Apache webserver installed anyway, it's easier to use it as the primary app entry point than to futz about with the tomcat config.xml.
Here's what I meant about changing the root context behavior: