Only some apps in web.xml run

[Rob Wehrstein]

I have eight web apps in the same WEB-INF/classes/ folder. They are all listed in the web.xml file. When I start Tomcat 6, only some of the apps run. I am able to run the other apps, but to do so, I have to recompile them and then restart Tomcat. Am I doing something incorrectly?

[Bear Bibeault]

Rob Wehrstein wrote:I have eight web apps in the same WEB-INF/classes/ folder.

No, you don't. Each folder with a WEB-INF subfolder defines one web app (context). If you've got them all mixed up in the same folder, you have one web app, not eight.

Am I doing something incorrectly?

Yes. See above. Each web app should be completely separate form the others.

[Rob Wehrstein]

Bear Bibeault wrote:Each web app should be completely separate form the others.

I think what I mean is that I have multiple servlets in one folder. I see lots of example web.xml files online and these have multiple servlet mappings, which would essentially
mean multiple servlets.

To rephrase:

I have eight servlets in the same WEB-INF/classes/ folder. They are all listed in the web.xml file. When I start Tomcat 6, only some of the servlets run. I am able to run the other servlets, but to do so, I have to recompile them and then restart Tomcat. Am I doing something incorrectly?

[Paul Clapham]

The short answer is Yes. But you already knew there was a problem, so let's move on to solving it. So far all you said was that the servlets "didn't run". What are the symptoms of not running? Tell us about error messages, response codes, whatever you saw.

[Bear Bibeault]

Ah, yes, That's different.

Have you worked through the list of troubleshooting steps in the ServletsFaq?

[Rob Wehrstein]

Paul Clapham wrote:The short answer is Yes. But you already knew there was a problem, so let's move on to solving it. So far all you said was that the servlets "didn't run". What are the symptoms of not running? Tell us about error messages, response codes, whatever you saw.

I can point my web browser at the URL. The browser appears to load an empty web page that has no page source. I looked in the tomcat logs, but did not see anything that looked problematic.

[Tim Holloway]

If you didn't get a Tomcat 404 error page, the servlets ran. They just didn't return anything.

Use your browser's View Page Source option to see if they literally returned nothing or if they returned non-displayable content.

[Rob Wehrstein]

Tim Holloway wrote:If you didn't get a Tomcat 404 error page, the servlets ran. They just didn't return anything.

Use your browser's View Page Source option to see if they literally returned nothing or if they returned non-displayable content.

There was no error message. I clicked "View Page Source" and the page source is empty.

[Bear Bibeault]

Empty or incomplete responses are almost always a sign of an exception. Have you checked the logs?

[Tim Holloway]

Then the servlets in question returned nothing.

"Nothing" comes in several flavors. If you have a sophisticated client-side debugger such as Firefly, you can examine the details of the response stream and see if you got completely nothing or nothing but HTTP headers with no body. Plus you will see the HTTP response code.

Aside from that, you describe your server like you think Tomcat is something you can just throw stuff at and it gets served up. Tomcat is a J2EE server and requires webapps to be packaged in WAR format, either as an actual WAR file or as an exploded (unzipped) war residing in a directory directly underneath the TOMCAT_HOME/webapps directory (assuming default configuration).

[Rob Wehrstein]

The error goes away when the start up script is called from a specific directory. This directory contains an html file that the is read at run time by the servlet.

[Bear Bibeault]

That likely means you are using too general a path to the HTML file, which depends upon the very iffy concept of "current directory". Bad move.

[Tim Holloway]

To be more explict, in J2EE, you should not rely on a "current directory" or on stdin, stdout or stderr (System.in, System.out, System.err). Although the JVM inherits all of the preceeding from its general environment, a J2EE server makes little or no attempt to make them reliable. Other mechanisms more suitable for the web environment exists within J2EE.

In particular, the "current directory" can be randomly zapped to any place at any time with no notice whatsoever and that includes while you are in the middle of a method execution.

The best way to locate a resource in J2EE is either to use one of the ServletRequest getResource methods if the resource is within the WAR or to use a locator mechanism such as JNDI if the resource is external to the WAR. There's a method that will return the filesystem location of a resource as well, but that returns null if the WAR hasn't been exploded. And it's bad practice for a webapp to assume that the WAR was exploded, since that's determined solely by how the WAR was deployed, not by the system environment or program logic.