Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (herse.apache.org: local policy)
Date: Tue, 28 Nov 2006 10:52:27 -0700
From: Kris Nuttycombe <nuttycom@apache.org>
Subject: Re: DO NOT REPLY [Bug 39120] - Create semantics for "path" attribute
 in embedded context.xml
In-reply-to: <45512BFA.3070106@apache.org>
To: dev@tomcat.apache.org
Message-id: <456C775B.1050406@apache.org>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 1.5.0.8 (X11/20061105)
References: <2771e600611070836t2d773fc4v2d1f8c08fdcc75c2@mail.gmail.com>
 <45512BFA.3070106@apache.org>

Hi, Mark,

Thanks for your reply. Perhaps I should be stating the problem in terms
of how I would like to be able to deploy a web application and what was
possible under 5.0 instead of in terms of the problems I have
encountered. Here is what I would like to do:

I have a warfile, myapp-1.3.5.war which has an embedded
META-INF/context.xml file with information like the JNDI data source
configuration. This webapp is to be deployed on the host foo.example.com
at the path http://foo.example.com/fooco/webapps/somecategory/myapp. I
also do not have any access to our production webserver; in order to
deploy a web application, I need to be able to give this warfile to a
system administrator who knows nothing about Tomcat and have him deploy
the application. Under Tomcat 5.0 and previous releases, I was able to
simply have him drop the warfile in the $CATALINA-HOME/webapps directory
and everything would work fine. If I gave him a new version,
myapp-1.4.0.war, he could look in the webapps directory and see that
myapp-1.3.5 needed to be replaced.

 From my experience, under tomcat 5.5, myapp-1.3.5.war has to be put
into some other tomcat-accessible directory on the server, and the
content of the embedded context.xml file has to be extracted and added
to the server.xml file. This means that manual intervention of the
sysadmin is required, where before we were able to have an rsync'ed
staging directory on a server to which our developers have access; we
would simply drop the warfile there and it would automatically be copied
out to the production server during the maintainance window.

If there is a way to make things work like they did under Tomcat 5.0,
please, please let me know. I interspersed a few more comments below.

Thanks,

Kris

Mark Thomas wrote:
> Kris Nuttycombe wrote:
>   
>> Is there any documentation on the rationale behind this change?
>>     
> As far as I recall, there were a number of posts to the dev list back
> when the 5.5.x branch was being proposed. The (very) short version was
> to make things simpler and less buggy.
>   
>> It is
>> extraordinarily inconvenient as it prevents the deployment of a
>> context at any path other than the server root unless you unpack the
>> warfile - effectively making straight warfile deployment impossible in
>> such a case.
>>     
> Maybe I am missing your point but you can deploy a war at any path you
> like without having to unpack it. Options include:
> - in individual files (with a ".xml" extension) in the
> $CATALINA_HOME/conf/[enginename]/[hostname]/ directory
>   

You're talking here about the context.xml file. When a warfile is simply
dropped in to the $CATALINA_HOME/webapps directory, the context.xml file
is extracted from META-INF and placed in the correct location; however,
the value of the "path" attribute appears to be ignored.

> - in individual files (with a ".xml" extension) in the
> $CATALINA_HOME/webapps directory
>


I have not been able to get this approach to work at all. I presume that
you're talking about the context.xml file here? When I put myapp.xml in
this directory, the webapp is not found at all.

> - rename the war
>   

This doesn't solve the problem of having the webapp deployed in some
deep directory structure.

>> In my shop, developers use the
>> manager web application to deploy our applications and don't have
>> write permissions for server.xml - but need to be able to deploy
>> applications that don't have paths at the server root.
>>     
> And the manager doesn't (or at least it shouldn't) stop them doing this.
>
> Mark
>
>   

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