We handle the same issue by creating a context.template, which has variables
and we use ANT to perform the following steps:
1) Copy context.template to META-INF/context.xml
<!-- Part of ANT task -->
<copy file="${context.template}" tofile="META-INF/context.xml"/>
<!--This is the context.template with a variable @[foo] -->
<Context>
<Resource name="mail/Session"
auth="Container"
type="javax.mail.Session"
mail.smtp.host="@[foo]"/>
</Context>
2) Replace the variables with variables defined in the build.properties file
<!-- Part of ANT task, where ${bar} is defined in build.properties-->
<replace file="META-INF/context.xml" token="@[foo]" value="${bar}"/>
3) Create the war with the new context.xml
If anyone has other solutions, please share :)
-----Original Message-----
From: Tim Lucia [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 23, 2006 4:25 AM
To: 'Tomcat Users List'
Subject: RE: Redeploying war file kills context xml
In a previous life, we actually wrote an installer, of which a good part of
the effort involved merging the existing (old) context file and the new one,
just to preserve settings customized by the customer. (It worked similarly
on the web.xml)
I too think it would be a nice feature if certain settings could be
preserved. The <Environment...> and <Resource...> elements could provide a
default value, or an override flag (or force) which keeps / overrides any
old value(s) found. Deleting a no-longer-used value becomes problematic
(you can just leave it of course, but that might confuse the end user.)
Tim
-----Original Message-----
From: Aust, Christian [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 23, 2006 2:58 AM
To: Tomcat-Users (E-Mail)
Subject: RE: Redeploying war file kills context xml
Hi Jim,
thanks for your reply. Defining the context outside the war file solves some
issues, since we deploy the very same application to different server
setups. JNDI environment values are different on test and production
machines, and those are defined in the context.
Adding them to the war file under META-INF/context.xml would mean to produce
different war files for each deployment server. That's why it's annoying
that tomcat keeps deleting those manually edited files from it's
configuration. Kind regards,
- Christian
> -----Original Message-----
> From: Jim Freeby [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 22, 2006 7:50 PM
> To: Tomcat Users List
> Subject: RE: Redeploying war file kills context xml
>
>
> I am using Tomcat 5.5.15 w/ jdk1.5.0_06
>
> In my webapp, I have created a context file in
> ${app.name}/META-INF/context.xml.
>
> If Tomcat is running and I drop a new war file in the webapps
> dir, Tomcat reads ${app.name}/META-INF/context.xml and
> creates a new
> ${catalina.home}/conf/Catlina/${host.name}/${app.name}.xml
> This seems like the correct way to do things (not a
> workaround), because your context is defined and deployed
> with your webapp.
>
> From the Tomcat documentation
> (http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html):
> "A Context is what Tomcat calls a web application."
>
> You could also define your context in server.xml, but this is
> discouraged in the Tomcat docs.
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service.
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
!DSPAM:442293e5203084359117518!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
