tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evan J " <>
Subject Re: Autodeployment of web.xml Does Not Work
Date Tue, 18 Apr 2006 02:54:53 GMT
Ok, new revelations...

I believe I figured out What I was doing wrong. It turned out that
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,


And having url-mapping of `/functioning/myservlet' for package.MyServlet, then
it should be accessed:

Rather than:

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,


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

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 <> wrote:
> On 4/15/06, Wendy Smoak <> wrote:
> > On 4/15/06, Evan J <> 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...
> >
> > > (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.
> >
> >  *
> >
> > 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:
> > For additional commands, e-mail:
> >
> >
> 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:
For additional commands, e-mail:

View raw message