I'm hoping someone will take pity on a tomcat beginner and help me figure out what happened..
Ok, so I've set up a server over at linode, running ubuntu, apache2 tomcat6 jkmod mysql etc. nothing fancy there, I've managed to get everything running smoothly by following various tutorials (I've never set up a tomcat server before, inc. jkmod). I have virtual domains working, I'm hosting 3 sites on it and have for a few months now.
Last night I went and uploaded a new file to an admin backend I created, nothing odd there, just an update to a single file.
Now I get 404's on subfolders.
I'm getting the 404 from tomcat, saying the resource is not available but if I type in the name of a file, it shows the contents of the file. It only seems to recognize HTML files in subdirectories now.
It all worked fine the day before.
I'm using OpenBD, btw. with file endings .cfm
I did forget to say that I've tried to research this but so far I haven't found anything about this problem, my first reaction is not to go ask on a forum but rather to do my research.
After a bunch of mucking about I've got some more info; I only get 404's when using the virtualhost.
If I use the ip and folder names, it works just fine, but if I use the domain name (Which goes through apache2 and jkmod) tomcat throws a 404 (Yes, it's tomcat6 that throws the 404).
It's hard to tell for certain from what you've said, but I'm going to take a stab at it based on what you didn't say.
J2EE web applications are not just "files on a server". They are self-contained bundled components. In fact, their only official format is the WAR format (more or less - Tomcat doesn't do EAR format).
A JAR is a ZIP file+manifest. A WAR is a JAR file+WEB-INF and various other concepts. In plain terms, it has to have an certain definite directory structure and support files.
In the Real World, a lot of webapp servers support what are known as "exploded WARs", and that includes Tomcat (when it's running under default settings). An exploded WAR is simply a WAR file that was unzipped into a discrete set of files and directories. If you're working with an exploded WAR, you can (within limits) hot-update individual resources (files) within that WAR. Which is more or less where you come in.
The point is that it doesn't work properly if the webapp isn't in a proper WAR format, whether exploded or zipped. Everything else is secondary.
Relating to that is that Tomcat (and the other J2EE webapp servers) are NOT file servers, they are web servers. A URL is not a filename path, it's a resource locator. IF the webapp chooses to pull that URL apart and use it to locate a file-type resource, that's fine, but the webapp doesn't have to do that if it doesn't want to. In a WAR, the WEB-INF/web.xml file defines how URLs map to webapp components (servlets). Tomcat will use this information to route the URL.
If none of the mappings in WEB-INF/web.xml match up to the incoming URL, Tomcat will pass the URL to its Default Servlet. The Default Servlet will examine the URL, and if it ends with ".jsp", attempt to locate a corresponding JSP, which may include compiling the JSP source file to product a servlet class which then gets the URL request sent to it. If it does not end with JSP and the default servlet cannot figure out anything else to do with the URL, it breaks down the URL into a webapp local resource path and looks it up in the WAR. For an unexploded WAR, that means, it looks for the appropriate component of the WAR ZIPfile. For an exploded WAR, it looks for the appropriate subdirectory path in the exploded WAR directory. If that resolves to a directory, Tomcat will build a directory listing page and display it. If it resolves to a file, Tomcat will copy the contents of that file to the response stream, as well as create whatever response headers it figures are required.
AND, if none of the above work, Tomcat will create a "404" error page and display it.
There are some additional considerations as well. Tomcat doesn't immediately reflect updates. It scans the WAR at (fairly short) intervals, and only shows the changes after the scan.
Customer surveys are for companies who didn't pay proper attention to begin with.
Joined: Apr 14, 2012
Thanks for the welcome, Tim!
Ok, here's where I'm at and what's going on (Starting over here).
I have a server running Ubuntu LTS, set up to be a webserver with Apache2, MySQL, jk_mod, and Tomcat 6.
I have multiple sites hosted so I'm using virtual hosts from apache through jk_mod to be served by tomcat.
I'm creating CFML sites using OpenBD (Which creates a WAR file to be deployed on a Java server).
It works great and I'm very pleased with it all at this point, the issue I'm running into right now is this;
(The url is not the real one)
If I type for example www.mysite.com/administration/
I get a 404.
But if I type the server IP and folder like this;
It lets the servlet process the folder and it works fine.
Note that the 404 is from tomcat.
So somehow, using the URL breaks something with tomcat.
I've yet to figure out what.
I understand the overall difference between for example apache and tomcat, but I'm no expert on tomcat and my research have yet to find a solution to this odd url issue.
Actually, what you're describing sounds like the exact opposite. If you can get the proper response from the port 8080 but not from the public form of the URL, that would indicate a problem with the server that's fronting Tomcat.
Tomcat's "404" page is visually distinct from Apache's "404" page, so unless they've been customized, it's usually easy to tell which one is complaining.
Joined: Apr 14, 2012
Yes, that's one of the things that I don't get.
It's tomcat throwing the 404, not apache.
IP/appfolder/subfolder <- Works
www.site.com/subfolder <- Tomcat throws a 404