Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
From: Jeffrey Janner <Jeffrey.Janner@PolyDyne.com>
To: 'Tomcat Users List' <users@tomcat.apache.org>
Subject: RE: Why is context.xml no longer copied to
 Catalina/localhost/myapp.xml?
Thread-Topic: Why is context.xml no longer copied to
 Catalina/localhost/myapp.xml?
Thread-Index: 
 AQHOSakwlLPcRe1RGUivcbs9qolG2pj3FmqAgAGBF4CAAC60AIAALLyAgAAHEQCAAPIM8A==
Date: Tue, 7 May 2013 16:32:27 +0000
Message-ID: 
 <7215BA462D00D343B2837F9113F0131F0146F26A43@POSTOFFICE02.polydyne.com>
References: <B355C660-FE62-48EA-AB5D-B094C75D9928@360works.com>
 <51868449.8040408@apache.org>
 <C476BF52-C3CF-4F45-8618-BD9FB1282623@360works.com>
 <5187EE80.3020802@apache.org>
 <558F9847-19B5-4399-99EB-C589EFD59C01@360works.com>
 <518819F4.8070200@apache.org>
In-Reply-To: <518819F4.8070200@apache.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1
X-SEF-Processed: 7_2_0_00504__2013_05_07_11_39_12
X-Virus-Checked: Checked by ClamAV on apache.org

> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org]
> Sent: Monday, May 06, 2013 4:01 PM
> To: Tomcat Users List
> Subject: Re: Why is context.xml no longer copied to
> Catalina/localhost/myapp.xml?
>=20
> On 06/05/2013 21:35, Jesse Barnum wrote:
> > On May 6, 2013, at 1:55 PM, Mark Thomas <markt@apache.org> wrote:
> >
> >> Right now, probably not.
> >>
> >> There are a couple of issues in this area (the thread I referenced,
> >> unpacking WARs outside the appBase into the appBase, lack of clarity
> >> on exactly what the expected behaviour in any given scenario) that I
> >> am actively working on. My rough plan is:
> >> - document what I think should happen (as simply as possible - this
> >> is proving to be the hard part as there are so many variables)
> >> - present this to the community for discussion / feedback
> >> - implement it for 8.0.x
> >> - probably back-port it to 7.0.x
> >>
> >> For you particular scenario I am considering allowing per Context
> >> override of copyXML that would enable your app to work as you want
> in
> >> a default Tomcat 7 install. Every new option, however adds to the
> >> overall complexity so I am still working through this.
> >>
> >> Watch this space.
> >>
> >> Mark
> >
> >
> > Make sense - thanks Mark.
> >
> > I am sure that this would be out of scope, but if we pictured an
> ideal scenario, it seems like there would be one configuration file
> that is tightly managed by the developer, which is replaced when the
> app is redeployed, and a different configuration file that is intended
> for end user customization, which is stored separately.
>=20
> The way to do that is to keep copyXML=3Dfalse, parameterise [1] the META-
> INF/context.xml and then specify the necessary parameter values in
> catalina.properties.
>=20
> That way the developer is free to manage META-INF/context.xml but any
> updates won't change the parameterised values.
>=20
> If the app doesn't fail to start if the parameters are set, it should
> be easy to add a ServletContextListener to make sure that it does.
>=20
> Mark
>=20
> [1] http://tomcat.apache.org/tomcat-7.0-doc/config/index.html (2nd
> para)
>=20

Which won't necessarily work for those of us who deploy into multi-tenant (=
multi-host) environments.
For example, each context.xml might have a DB resource that has to be custo=
mized differently for each tenant/host.
We certainly don't want to have to modify each context.xml with every new v=
ersion that is produced, and they certainly could not use the same paramete=
r for substitution.  In that case, it's a one and done scenario, unless the=
re are mods to the context.xml that are required by the new app release.
Just one of those may varying scenarios you were talking about.
Jeff


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