Question

We have a web app with the following folders/files:

somefolder\
view1.jsp
view2.jsp

We also have a servlet that is configured as follows:

<servlet>
    <servlet-name>Servlet1</servlet-name>
    <servlet-class>com.etc.Servlet1</servlet-class>
</servlet>

<servlet-mapping>
    <servlet-name>Servlet1</servlet-name>
    <url-pattern>/somefolder/</url-pattern>
</servlet-mapping>

The desired result is:

• Navigate to http://some.site/somefolder <– should be handled by com.etc.Servlet1
• Navigate to http://some.site/somefolder/view1.jsp <– should be handled by the jsp processor

On our live Tomcat 5 site, the above works fine. On our development Tomcat 6 systems, the above works fine.

But on our new live Tomcat 6 site, the above doesn’t work. I get 404 errors when navigating to http://some.site/somefolder

If we rename the somefolder\ folder in the filesystem to be somefolder2\ , then the servlets work properly.

Given the difference between behavior of different installations, this makes me wonder if it doesn’t have to do with Tomcat configuration – maybe Tomcat is seeing the physical directory, and handling that with some other servlet (the Default servlet maybe??), and never giving our servlet-mapping a chance.

Does anyone have any suggestions on how to attack this?

EDIT: More information:

Digging in a bit, I’m finding that by JNDI resources are not available for jsp files in any sub-folder, but the JNDI resources are available in servlets configured in web.xml. It looks like maybe Tomcat is creating separate contexts for each sub-folder. Is that possibly what’s going on?

EDIT: More info:

I added a debugging line that displays the context path, and sure-enough – the jsp files in the sub-folder are indeed running in their own context. So how could Tomcat be implicitly creating contexts for each sub-folder in the web app? We definitely aren’t creating these context’s ourselves.

Answer 1

The solution here was to leave the webapp path set to the default location, and specify special folders for each context (under Tomcat 4, you could do this by setting the webapp location, but the behavior has, apparently, changed).

Easy enough fix.