File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Tomcat and the fly likes Only some apps in web.xml run Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "Only some apps in web.xml run" Watch "Only some apps in web.xml run" New topic
Author

Only some apps in web.xml run

Rob Wehrstein
Greenhorn

Joined: Sep 30, 2013
Posts: 11
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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61221
    
  66

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.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Rob Wehrstein
Greenhorn

Joined: Sep 30, 2013
Posts: 11
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
Bartender

Joined: Oct 14, 2005
Posts: 18570
    
    8

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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61221
    
  66

Ah, yes, That's different.

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

Joined: Sep 30, 2013
Posts: 11
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
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
Rob Wehrstein
Greenhorn

Joined: Sep 30, 2013
Posts: 11
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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61221
    
  66

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

Joined: Jun 25, 2001
Posts: 16065
    
  21

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
Greenhorn

Joined: Sep 30, 2013
Posts: 11
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
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61221
    
  66

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
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16065
    
  21

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Only some apps in web.xml run