tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig Longman <cra...@begeek.com>
Subject Re: trying to understand contexts
Date Sat, 24 Aug 2002 04:26:41 GMT
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.

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.

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>

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

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.

> 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:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> >For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
-- 

    CraigL->Thx();
    Be Developer ID: 5852



--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message