1) No, you don't *have* to. But you gain some advantages with the double-indirection (you call '/foo' from the browser, which calls the servlet named 'myXYZservlet', which finally resolves to 'com.mypackage.anotherpackage.className'). They include (but aren't limited to) hiding of class names, increased security, a "nice" looking address bar and the normal advantage of having an alias... being able to switch what something "points" to, without having to re-write anything that used the alias. All that, and it is the recommened way of doing things.
Having said that.. whatever way you choose to proceed, pick ONE and ALWAYS use that way. Either use the invoker servlet and call everything like /servlet/classNameHere or ALWAYS use an alias and never use /servlet.
2) depends.
*IF* your ISP has the invoker servlet enabled, then yes,
you should be able to invoke your classes, with /servlet/classNameHere. In fact, if you go this route, you should probably leave your web.xml empty of servlet and servlet-mapping tags.
*IF* your ISP has disabled the invoker servlet, which they should, then serlvet/* should never work, unless you explicitly enable it, and you MUST provide servlet and servlet-mapping tags in appropriate pairings.
I think the answer to why the odd behaviour is happening is answered by your next question...
3) the servlet tag is 1/2 of how Tomcat finds servlets. YOU make a request of a certain
url-pattern. So the
servlet-mapping entries are the missing 1/2, and it's the 1st half as well. Your URL request is translated to a
servlet-name, which is then translated to a
servlet-class.
As for your ISP's file.. NO. I've never seen that before, and I think it's the cause of your trouble. A context's meaning is "web application". There is only one entry point to that application. Remove any entries with anything after /jserv (all the ones with /classes/etc/etc...)
4 ) See above. That server.xml file is *wrong*
[ March 26, 2003: Message edited by: Mike Curwen ]