tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 4829] - Automatic deployment of war files does not work properly
Date Fri, 22 Mar 2002 18:36:33 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4829

Automatic deployment of war files does not work properly





------- Additional Comments From pfg@usinternet.com  2002-03-22 18:36 -------
I have also observed this behavior. This probably could be considered more of a 
bug in the documentation than the code. The 4.0 on-line docs state you can "set 
(the unpackWARS attribute of a <Host> element) to true if you want web 
applications that are deployed into this virtual host from a Web Application 
Archive (WAR) file to be unpacked into a disk directory structure." They also 
state that "(y)ou can nest one or more Context elements inside this Host 
element, each representing a different web application associated with this 
virtual host."

As to Context, "(t)he <Context> element represents a web application, which is 
run within a particular virtual host. Each web application is based on a Web 
Application Archive (WAR) file, or a corresponding directory containing the 
corresponding unpacked contents...", and that"(e)ach (<Context> element) MUST 
have a unique context path, which is defined by the path attribute."

The docs don't say that before Tomcat unpacks any warfiles, it will first 
attempt to verify the context path of a <Context> element by checking for a 
web.xml file in the corresponding webapp WEB-INF directories. It also doesn't 
state that if it can't find the web.xml file in the context path directory 
referenced by the <Context> element, it will shut down.

If anything, the desired behavior should be the opposite: unpack the warfiles, 
then check the <Context> elements in server.xml against the appropriate 
web.xml. That might be a little less irritating than not.

PaulGarvie

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


Mime
View raw message