Let's consider this servlet mapping in web.xml that defines "App" as the default servlet:
<servlet-mapping>Now call http://server/context/path/to/test.html. Here are the request properties:
- getPathInfo() : null
- getServletPath() : "/path/to/test.html"
Let's change web.xml like this, so that "App" eats the same URLs but is no more the default servlet:
<servlet-mapping>And call again the same http://server/context/path/to/test.html:
- getPathInfo() : "/path/to/test.html"
- getServletPath() : "" (empty string)
In the "Mapping request to servlets" chapter, the specification of mappings is described:
- A string beginning with a ‘/’ character and ending with a ‘/*’ postfix is used for path mapping.
- A string beginning with a‘*.’ prefix is used as an extension mapping.
- A string containing only the ’/’ character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.
- All other strings are used for exact matches only.
So that means that a servlet that needs to map a resource according to the request URL must behave differently depending on whether it is defined as the default servlet or mounted to a particular location. What's the reason for this???
Good old Cocoon fixes this by simply concatenating the path info and servlet path, so that your application doesn't have to care about it.
Hmm... I'm going to write a "ConsiderTheDefaultServletAsAnyOtherServlet" request filter that will do the same...