tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <>
Subject Re: trying to understand contexts
Date Sat, 24 Aug 2002 17:43:05 GMT
At 12:26 AM 8/24/2002 -0400, you wrote:
>On Fri, 2002-08-23 at 22:43, Jacob Kjome wrote:
> > Hi Craig,
> >
> > First, one thing to note is that your contexts don't actually have to be
> > registered in the server.xml if they are deployed from the
> > $TOMCAT_HOME/webapps directory.  A context will be created 
> automatically by
> > Tomcat.  The only reason why you might want to add a <Context ...> element
> > for a particular context is to add some non-default configuration info.
>yes, i see that to.  i wish actually there was some way of turning it
>off, at least to achieve what i'm trying to achieve.  more below...
> > Now we get to the ROOT context.  You will notice in Tomcat's webapps
> > directory, there is a directory named "ROOT".  That name is a special case
> > for Tomcat.  Any context named ROOT (case sensitive, I believe) will be 
> the
> > default context served off of the path http://localhost:8080/
> >
> > What you can do is place your own webapp inside the ROOT directory and
> > rename the one that came with Tomcat.  Also, if you want to provide some
> > extra non-default configuration info for the ROOT context, you can add the
> > following:
> >
> > <Context path="" docBase="ROOT" debug="0">
> > ....
> > ....
> > ....
> > </Context>
> >
> > Notice the the "path" attribute value is "", not "/".
> >
> > Also, note that your docBase can be of any name as long as you have a
> > defined <Context ...> element pointing to it and have the path as
> > "".  Actually, I'm not sure what would happen if you had that and then had
> > a ROOT directory in the webapps directory without any <Context ...> 
> element
> > defined for it?  You'd have to test that out.
>it seemed to load the servlet code fine into ROOT, but it also insisted
>on loading the webapp again from the directory that it is located in
>into a separate context.

If you had the same servlet in two different contexts then It would make 
complete sense that it would be loaded once for each context defined 
whether the definition was done by you or done by default

>what i'm trying to achieve, is to have every file with an extension of
>'vtpl' processed by my servlet.  everything else is unnecessary.  if i
>use the ROOT thing, then i can't reload it from the manager app.  if i
>don't provide an empty path, then everything on the website needs to
>live in a subdirectory off the url.

If there wasn't the concept of a ROOT application and all apps lived under 
the same context, you would have apps bumping into each other when 
attempting to deploy a distinct web application with its own set of defined 
servlets/mappings/environment variables and such.  You really can't live 
without having different contexts defined and how else would you define 
them except for different directory paths using http?

>perhaps i'm expecting too much of tomcat here.  perhaps if i changed the
>apache entry to just read:
>  DocumentRoot /var/tomcat4/webapps/host1/app1
>  JkMount *.vptl ajp13
>  <Location /WEB-INF>
>   order deny,all
>   deny from all
>  </Location>

First, let's leave Apache out of it for the time being.  That only confuses 
things.   Access Tomcat directly using port 8080 to tetst this stuff.

>and then maybe also block the context name (app1 in this case) from
>being browsed directly.

I just tried defining a context with a path="" and removed the ROOT app.  I 
think I now see what you are saying.  If you go to http://localhost:8080/ 
you will see the app that you defined with the empty path, but you will 
also see the same app defined at the name of the directory that the app 
exists inside, so you can get to it by either http://localhost:8080/ or 
http://localhost:8080/fooroot/ . The only exception is if the directory is 
specifically named "ROOT".  If you go to 
http://localhost:8080/manager/html/list you will see that the ROOT 
application is still defined and it has a path, there, of "/", but there is 
also a path defined as the name of the directory my app exists in which is 
"/fooroot".  Now, there are no start/stop/reload/remove entries for the 
ROOT webapp, but there are for the "/fooroot" webapp.  If I stop that one, 
the only one it affects is the one at http://localhost:8080/fooroot/ , but 
the one at http://localhost:8080/ never gets stopped.  I can see where that 
would be annoying since if you define a context that you want to run under 
the root of the app *and* you want to reload it, *and* you don't want it to 
be redefined under "/fooroot", you have no recourse with Tomcat as I see 
it.  I guess the one way that you don't have it redefined as "/fooroot" is 
for the directory to be named "ROOT", but you still can't reload it.

>this should achieve what i want, right?  any time a .vtpl file gets
>loaded, it will be sent to tomcat, and i have the mapping setup in the
>web.xml, but will the fact that the url is http://host/xxx.vtpl not
>http://host/app1/xxx.vtpl cause more headaches?
>to answer my own question, it does cause headaches, i just tested it.
>trying to have host/xxx.vtpl passed for processing by my servlet doesn't
>work, tomcat tells me there is no context configured for the request.
>what am i missing here?  it seems like these contexts being forced
>subdirectories of the url is being really restrictive here.  i'm not
>sure if i'm being strange in just wanting the whole site to have the
>dynamic content files parsed, or just obstinate for not wanting to put
>the whole site in a subdirectory.
>why is the ROOT context not allowed to be reloaded?  that seems strange,
>and it means although i could deploy with the ROOT context handling
>things, i can't develop that way.

Having the ROOT context reloadable would be the solution.  You would then 
have to get rid of all other defined/undefined contexts (meaning remove all 
server.xml entries + remove all directories under webapps not named 
ROOT).  If this was possible, then it would acheive what you are getting 
at.  I guess I have to admit, it doesn't seem possible in the current 
architecture.  Maybe someone else can prove us wrong.

The one thing you can do to work around this is to have a servlet that 
captures all paths under ROOT which forwards to the proper context such as 
your "/app1" directory and, again, have no other contexts defined.

Sorry I couldn't say anything more positive :-(


> > Anyway, that should clear up some of the mystery.  Write back if you have
> > more questions.
> >
> > Jake
> >
> > At 09:34 PM 8/23/2002 -0400, you wrote:
> >
> > >hi there,
> > >
> > >i am trying to wade through the configuration of tomcat now, and i'm
> > >terribly confused about a few things.  pretty much all of the time when
> > >i've created sites before, i've simply had a servlet process certain
> > >filetype extensions or such, without much regard for what directory
> > >things are located in.  occasionally, a servlet would be invoked
> > >directly with a url something like /servlet/XXX.
> > >
> > >with tomcat however, it seems that directories are king.  everything
> > >needs to be in a directory, and its frustrating.  i just spent a great
> > >deal of time trying to make a context with a path of "/" work, but to no
> > >avail.  the documentation says that i MUST (emphasis in the docs) have a
> > >context with a blank path, but the example server.xml file has it
> > >commented out.  whenever i tried to use the context with path="/", i
> > >would simply get 'no context available' error messages.
> > >
> > >anyway, i'm trying to set things up so that everything off of the root
> > >directory are processed by my servlet engine, based on the file
> > >extension, much like jsp files work.  the problems are:
> > >
> > >1) using path="/" just doesn't work.  is this a bug?  if not, why is
> > >this not a valid context.
> > >2) using path="" seems to invoke my servlet ok, but then for some reason
> > >the 'reload' option in the application manager disappears. this means i
> > >need to restart the server every time something changes, not exactly the
> > >quickest development path.
> > >3) just go with the flow and make my site(s) oriented around a directory
> > >off of the main directory.  i guess this would be the simplest, but it
> > >just seems strange.
> > >
> > >so, any pointers that could help me understand whats going on would be
> > >helpful, i guess i'm just too used to the simple old jserv way of doing
> > >things, where you had files be processed anywhere (if the extension
> > >matched), and /servlet/XXX as the way to invoke other servlets.  is this
> > >style mimicable in tomcat?
> > >
> > >btw, this is 4.1.9 (beta).
> > >
> > >sincerely,
> > >
> > >--
> > >
> > >     CraigL->Thx();
> > >     Be Developer ID: 5852
> > >
> > >
> > >
> > >--
> > >To unsubscribe, 
> e-mail:   <>
> > >For additional commands, e-mail: 
> <>
>     CraigL->Thx();
>     Be Developer ID: 5852
>To unsubscribe, e-mail:   <>
>For additional commands, e-mail: <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message