tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smith <>
Subject Re: Problem with JNDI environment entry resources
Date Wed, 03 Sep 2008 16:50:37 GMT
I'm out then.  I'm fine with the way tomcat operates and don't feel 
anything in the way context xml files are associated with webapps is 
ambiguous.  It's really simple:

1. If you just want to deploy a webapp and don't need to define any 
resources like db pools, just drop the webapp in the webapps folder.  
The context xml file is not needed for such a basic deployment.  The 
context path will be the name of the webapp.

2. If you need resources defined, then create a context xml file named 
after the webapp and placed in conf/EngineName/HostName.

3. Only define the docBase attribute of a <Context ..> ... </Context> 
element if your webapp live's outside the appBase of any of tomcat's 
<Host .... > ... </Host> definitions in server.xml.

I'm sure if you'd like to make changes you could check out the tomcat 
source, make your changes, create a patch, and submit your proposal in 
Bugzilla for the tomcat committers to take a look at.  If you feel the 
true problem is in the docs, patches are accepted for that as well.


Paul Pepper wrote:
> 2008/9/3 David Smith <>:
>> There's an implicit association based on the context path.  myWebApp.xml in
>> conf/Catalina/localhost is implicitly associated with the webapp myWebApp in
>> the webapps directory, whether it be as a .war or expanded folder.
> Yes, I agree that the docs read this way. The point under discussion
> here was the use of a <Context/> docBase within server.xml - it's
> necessary in order to disambiguate the use of a <Context/> to a
> specific application.
>> Illegal may be a strong word -- it implies that tomcat will flat out reject
>> the context when you define a docBase.  If there is a docBase attribute
>> defined, it may be ignored if there's a webapp in the webapps directory
>> matching the context name (as defined by the *name* of the context xml file
>> in conf/{Engine Name}/{Host name}, not the path attribute of <Context
> I don't understand "may be ignored". Either docBase is ignored in this
> situation, or it isn't.
>> ...>....</Context>).  Worse, if the name of your webapp in webapps is
>> different than the name of the context xml file in conf/{Engine Name}/{Host
>> name}, you can get a double-deploy.  Only one instance of the webapp will
>> have the additional settings provided by the context xml file though.
> I'm afraid I haven't encountered this behaviour described in the docs.
> I'd be grateful of a reference to it. Where documentation is missing,
> or where further clarity is required (as suggested by repeated
> user/developer mistakes), what is the procedure within Apache for
> helping make this happen?
>> Best practice overall is don't specify a docBase attribute unless your
>> webapp is outside the appBase you are deploying the application to.  Some
>> people have reasons for doing this -- like when they absolutely have to have
>> the war file named in some specific way that doesn't match the context path.
> That suggests that you've encountered cases where it is reasonable for
> the docBase and the context's xml file name to differ. However, the
> ambiguity in the use of docBase (re. above), and the double deployment
> problem that you mention, makes it difficult to solve this problem -
> worse if the use of <Context/> taken away as an option.
> If it's agreeable to the guys that have responded so far, then I'd
> like to get this discussion onto a thread of its own so that the
> subject reflects the discussion and mail headers refer to a specific
> topic. If you'd like to continue the discussion about <Context/> that
> we have started here, then please give me a little time to post this
> question as another message on this list - referring to this thread in
> the archives to avoid repetition.
>>  Also don't define a path attribute unless your <Context ... > ...
>> </Context> element is in server.xml (absolutely NOT recommended).
> Agreed!
> Thanks,
> Paul.

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message