aspose file tools*
The moose likes Tomcat and the fly likes 404 - the requested resource is not availabe... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » Tomcat
Bookmark "404 - the requested resource is not availabe..." Watch "404 - the requested resource is not availabe..." New topic
Author

404 - the requested resource is not availabe...

Tony Kemp
Greenhorn

Joined: Oct 15, 2002
Posts: 14
Hi all,
I've com across a very frustrating error with Tomcat 4.1.12 - it can't seem to find and/or load my servlets. Every other web app (examples, ROOT, another developer's) works, but mine doesn't there are no errors reported anywhere, either in the logs or stdout. This is running on Windows 2000 Server. This web app works, as I've had it working on tomcat 4.1.9 on linux and on this win2000 server.
It has no trouble with the JSPs, but simply will not load any of my servlets. And, yes, I've checked the obvious, and servlets are there, where they're meant to be.
Here are the relevant files/sections of files:
web.xml:

context from server.xml:

And here is a complete section from my logfile:

I'd be grateful for any help/suggestions anyone may make,
Tony.
Chris Reeves
Ranch Hand

Joined: Apr 03, 2002
Posts: 95
Tony -
What path are you requesting when you get a 404?
Tony Kemp
Greenhorn

Joined: Oct 15, 2002
Posts: 14
I use /vlis/servlet/framework.Main when calling the Main class in the framework package in the vlis context. This is the path that always worked on all the previous installs.
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

Tony,

in your web.xml you map framework.Main to the URI /main

Have you tried /vlis/main ?? This is what one would expect to work. It's the whole point of doing those mappings.

But probably not, you are invoking it through /servlet/framework.Main (why have that mapping if you're going to call it this way?)

anyways.. in Tomcat 4.1.12, the default /servlet/* mapper is turned OFF by default because it is a security risk.

Look in server.xml and uncomment it.
Tony Kemp
Greenhorn

Joined: Oct 15, 2002
Posts: 14
Sorry, I usually do access the servlet that way, but I thought that I would make it clear exactly the class being called. Also, when I was first developing this webapp, I didn't have the mapping set up, so I'm used to typing out the full path And I get the same error with either invocation.
Thanks for letting me know about that change, I didn't actually read the release notes before. Unfortunately for some reason this configuration line is missing from my config file, so I can't uncomment it. I don't know why it would be missing, as I only coppied and pasted in my context config section to the server.xml file, I haven't done any other editing to it.
What is the configuration line, so that I can add it in by hand?
Thanks!
[ November 06, 2002: Message edited by: Tony Kemp ]
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

oops.. it might be in the 'default' web.xml file. I don't have tomcat on my current system. It's the one with the BIG huge comments in it, so i think that's the web.xml file. I can't even remember where it is (I don't think it's in conf). Maybe ROOT/WEB-INF ?
Tony Kemp
Greenhorn

Joined: Oct 15, 2002
Posts: 14
Ah ha! Found it!
And all is working now. Thanks very much for your help!
Tony.
Dirk Schreckmann
Sheriff

Joined: Dec 10, 2001
Posts: 7023
For those that might wonder exactly what to do to solve this problem, here's what I did (and what I'd guess Tony did).
In the conf directory, edit web.xml to uncomment "the mapping for the invoker servlet". The tag looks like this:You should now be able to place Servlets in the webapps/ROOT/WEB-INF/classes folder and be able to invoke them with http://[domain]/servlet/FooServlet


[How To Ask Good Questions] [JavaRanch FAQ Wiki] [JavaRanch Radio]
david eberhardt
Ranch Hand

Joined: Jul 02, 2002
Posts: 158
Thanks Dick - I was having the simalar problems until I came accross "Take another look at ?the aforementioned thread
My particular problem was that I could call on the sample servlets and they ran fine but when I tried to put one of my own in the root/web-inf/classes directory, I'd get the server error also.
found the code you mentioned in the web.xml file starting at :

But I am wondering -
how come calling "http://localhost:8080/examples/servlet/HelloWorld" works before I made that change
while "http://localhost:8080/servlet/HelloWorld" did not
[ March 20, 2003: Message edited by: david eberhardt ]
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

Hi david (and everyone else).

Sorry I must have had a brain-freeze when I couldn't remember where the servlet mappings where. ( in conf/web.xml)

The answer to why
http://localhost:8080/examples/servlet/HelloWorld
works, but
http://localhost:8080/servlet/HelloWorld
doesn't... is in a trick that the Tomcat authors pull on you.

As we know by now, since 4.1.12, the invoker servlet is disabled. They do this by defining the servlet in conf/web.xml , but commenting out the actual servlet mapping (also in conf/web.xml). But take a look at what it says in conf/web.xml regarding how all these web.xml files are combined:And sure enough, if you look in examples/WEB-INF/web.xml, you'll find tucked away quietly in its place, the servlet/* mapping.
david eberhardt
Ranch Hand

Joined: Jul 02, 2002
Posts: 158
Mike Curwen,
Thanks Mike.
OK - I read up some more on this whole thing at Configuring & Using Apache Tomcat 4
I specifically looked at Configure Tomcat - part "3. Enable the Invoker Servlet"
it starts by explaining:
The invoker servlet lets you run servlets without first making changes to the WEB-INF/web.xml file in your Web application.

then they mention that it has been turned off due to security flaw.
So now I understand you post a little more also - that without the default invoker servlet, you have to define things in each web.xml file per Web application (i.e. \examples)
THANKS.
[ March 23, 2003: Message edited by: david eberhardt ]
 
wood burning stoves
 
subject: 404 - the requested resource is not availabe...