tags:

views:

26

answers:

1

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:

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.