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.
--David
Paul Pepper wrote:
2008/9/3 David Smith <[EMAIL PROTECTED]>:
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: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
