Ok, new revelations... I believe I figured out What I was doing wrong. It turned out that autodeployment of WEB-INF/web.xml was actually working and being monitored. What I had been missing all along was misunderstanding of request-mapping to servlets.
So according to Servlet Specification and several other books, the path to a servlet is defined as URI request - context path. In other world, if you want to access a servlet on a web application, you must specify the context path which in this case is the name of your application. Therefore, /actual/path/to/webapp/yourapplication/WEB-INF/classes/package.MyServlet And having url-mapping of `/functioning/myservlet' for package.MyServlet, then it should be accessed: http://host.com/yourapplication/functioning/myservlet Rather than: http://host.com/functioning/myservlet Unless your application is the default or `ROOT' webapps in that case the URL mapping would not require `yourapplication' but in most cases you might as well believe `yourapplication' is not the default one. :) Furthermore, if you have a ROOT webapp which has a subdirectory with the same name of `yourapplication's name, then accessing a similar name file/servlet of the ROOT application will cause Tomcat to go haywire. (I was unforetunate to have two web applications with the same name deployed on two different virtualhosts but since one was the default webapp, things got really hairy as I was trying to access the same URI mapped/name servlets, ARGH!). For example, Yourwebapps/virtualhost ROOT myapplication hello.jsp myapplication hello.jsp Accessing ROOT's myapplication/hello.jsp may as well not give what you have intended to but rather `myapplication's. As far as the Context element working only in conf/server.xml, I figured out what it was wrong with my settings. Again, online documentations have failed to mention a subtle point regarding name convensions used for context config file. In order to have your context config for your host on a different file, rather than hardcoded in conf/server.xml do the following: 1) mkdir conf/{name of the engine in your server.xml} 2) mkdir conf/{engine}/{name of the host} 3) touch conf/{engine}/{host}/{application}.xml So, if you have noticed it is not `context.xml.default' but rather {application}.xml. I'll try to add more explainations later on to this thread as I know there are many frusturated people like me out there who this may assist them one way or another. On 4/15/06, Evan J <[EMAIL PROTECTED]> wrote: > On 4/15/06, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > On 4/15/06, Evan J <[EMAIL PROTECTED]> wrote: > > > > > But again, "ANY" classes that does not have "url mapping" in > > > WEB-INF/web.xml, would not be autodeployed even if Tomcat server is > > > restarted. So once again, any class that has an existing url-mapping > > > in WEB-INF/web.xml, can be recompiled and autodeployed upon placement > > > in WEB-INF/classes but no newly compiled class that does not have > > > url-mapping in web.xml can be autodeployed or deployed at all (or at > > > least I get status 404 when I point my browser to the servlet). > > > > If there is no mapping in web.xml, Tomcat doesn't know what to do with > > the request, so the 404 is expected. You can't just "point your > > browser to the servlet". At least, not unless you enable the invoker > > servlet... > > > > > http://vh.domain.com/SomeNewClass (or /servlet/SomeNewClass). > > > > ... and this URL containing /servlet/ makes me think you're working > > from some old documentation that expects the invoker servlet to be > > enabled. > > > > * http://tomcat.apache.org/faq/misc.html#evil > > > > You should put your servlet classes in packages and explicitly map > > them in web.xml. URLs matching those mappings are the only ones you > > can expect to work. > > > > Whether changes to web.xml are picked up without reloading the context > > is a different question. I always re-deploy for web.xml changes, so > > I'm not sure. > > > > You might want to try your experiments again, (using only URLs that > > match mappings in web.xml,) and post another (shorter!) question if > > you're still not seeing the behavior you want. > > > > -- > > Wendy > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > Hi, > > The reason I posted my question in such a long thread was because > I did not want any ambiguity as far as what has been done to tackle > the issue. And from your response, I take it you did not read the > post throughly. I wasn't following any document and the reason I > mentioned servlet/MyClass was because, as for one of my settings > in the Apache webserver, I had /servlet/* mounted for servlets but > I had long gone moved away from that. As far as packaging, I > mentioned that I had been trying to only examin this issue with > web.xml redeployment and used packaging where it's applied. > > My problem lies in the realm of not being able to re-deploy web.xml for > any modification. If I could get that to work, I would be more than happy > to use the url-mapping to map my new classes. Again, I can access > servlets accordingly with url-mapping already presented in web.xml > but since I cannot redeploy it, I have no other choice but to restart > the server. I wonder if I have understood the purpose of WatchedResource > in Context correctly... > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
