tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Lucia" <>
Subject RE: RE: context.xml
Date Wed, 01 Feb 2006 11:56:49 GMT
On a recent project, we did exactly this.  I.e., had an install shield
wrapper that managed the context (and embedded data sources), the server.xml
(for global data source definitions) and the war to be deployed.  The
installer managed an off-line (separate) copy of the application, and knew
how to merge and upgrade files.  It worked well enough, but it felt like a
'really big hammer' approach to something that should be simpler.  I.e. I've
always felt like I want to just ship the .war file and use that, combined
with the admin / manager tools to configure it.  BTW, another reason we
couldn't do this is because the admin doesn't allow for setting the
defaultCatalog property of a connection pool.


-----Original Message-----
From: Caldarale, Charles R [] 
Sent: Tuesday, January 31, 2006 8:55 PM
To: Tomcat Users List
Subject: RE: RE: context.xml

> From: Klotz Jr, Dennis []
> Subject: RE: RE: context.xml
> I am hoping to find a place for a context.xml to live where it will 
> never get deleted. That a customer can change and when we give them a 
> new war file, the context.xml changes that they have made will stick 
> around.

Perhaps you could provide your customers with an installation package that
provides the .war file and a master context copy for editing somewhere
outside of Tomcat, along with a deployment script that copies both the .war
and the edited context file into Tomcat.  [Sorry, that sentence was way too

 - Chuck

MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message