You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jesse Barnum <js...@360works.com> on 2013/05/05 17:56:36 UTC
Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
I thought that the purpose of having <Parameter> elements in the context.xml file was so that end users and server administrators could easily customize the application behavior of a deployed application.
If that's true, then why is the context.xml file no longer extracted in Tomcat 7? Leaving it in the application directory means that it's going to be overwritten (losing those customizations) every time the server admin redeploys my application, right? Doesn't that seem like a bad idea? Am I missing something?
I know that I write a set of instructions for my customers to modify their server.xml and add the copyXML attribute to revert back to Tomcat 6 behavior, but why? Why not leave the default behavior the way it was before, so that context.xml files can be customized separately from the deployed application? I couldn't find any bug report / RFE in the Tomcat bug database explaining why this change was necessary or beneficial.
--Jesse Barnum, President, 360Works
http://www.360works.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
Posted by Istvan Devai <is...@istvandevai.com>.
On 05/06/2013 11:00 PM, Mark Thomas wrote:
> On 06/05/2013 21:35, Jesse Barnum wrote:
>> On May 6, 2013, at 1:55 PM, Mark Thomas <ma...@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.
> The way to do that is to keep copyXML=false, parameterise [1] the
> META-INF/context.xml and then specify the necessary parameter values in
> catalina.properties.
>
> That way the developer is free to manage META-INF/context.xml but any
> updates won't change the parameterised values.
>
> 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.
>
> Mark
>
> [1] http://tomcat.apache.org/tomcat-7.0-doc/config/index.html (2nd para)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
Hi Thomas,
What if the customisation of context.xml is more than replacing a few
simple variables? (for example: adding a valve)
My exact problem is described in the thread titled "proper context
usage" from a few days before, but it essentially comes down to this:
I'd like to have a way to customize my app's context.xml in a way that
it is retained while deploying-undeploying with the manager. See the
mentioned thread for all ways I've tried to achieve this, without any
success.
Best regards,
Istvan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Why is context.xml no longer copied to
Catalina/localhost/myapp.xml?
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----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?
>
> On 06/05/2013 21:35, Jesse Barnum wrote:
> > On May 6, 2013, at 1:55 PM, Mark Thomas <ma...@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.
>
> The way to do that is to keep copyXML=false, parameterise [1] the META-
> INF/context.xml and then specify the necessary parameter values in
> catalina.properties.
>
> That way the developer is free to manage META-INF/context.xml but any
> updates won't change the parameterised values.
>
> 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.
>
> Mark
>
> [1] http://tomcat.apache.org/tomcat-7.0-doc/config/index.html (2nd
> para)
>
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 customized differently for each tenant/host.
We certainly don't want to have to modify each context.xml with every new version that is produced, and they certainly could not use the same parameter for substitution. In that case, it's a one and done scenario, unless there 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
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
Posted by Mark Thomas <ma...@apache.org>.
On 06/05/2013 21:35, Jesse Barnum wrote:
> On May 6, 2013, at 1:55 PM, Mark Thomas <ma...@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.
The way to do that is to keep copyXML=false, parameterise [1] the
META-INF/context.xml and then specify the necessary parameter values in
catalina.properties.
That way the developer is free to manage META-INF/context.xml but any
updates won't change the parameterised values.
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.
Mark
[1] http://tomcat.apache.org/tomcat-7.0-doc/config/index.html (2nd para)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Why is context.xml no longer copied to
Catalina/localhost/myapp.xml?
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Tue, May 07, 2013 at 01:17:40PM -0400, Jesse Barnum wrote:
> On May 7, 2013, at 9:40 AM, "Mark H. Wood" <mw...@IUPUI.Edu> wrote:
> > Well, the developer can simply pack into the app. whatever internal
> > configuration is needed, since he has ready access to the interior of
> > the app and can deposit on the classpath *.properties, *.xml, or
> > anything else he wants. He can have no certain knowledge of the app's
> > runtime environment and should not assume, only specify requirements,
> > and provide sensible defaults when there are some.
> >
> > The deployer, OTOH, has ready access to the app's environment,
> > including its Context, but should not be assumed to have such access
> > to the interior of the app.
> >
> > So this division of labor depends on the developer's discipline in
> > distinguishing internal vs. external configuration and coding the
> > app. to look in the proper place for each. I don't see a good way for
> > the container to make up for incorrect design in this area.
> >
> > --
> > Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
> > Machines should not be friendly. Machines should be obedient.
>
> Mark, can you give me an example of a use case where it is useful for the deployer to modify parameter values in the META-INF/context.xml file? Assume that at some point, a new version of the application will be deployed, and also assume that the deployer does not wish to re-apply the same customizations with each release.
Well, not really. My point was that things the deployer will want to
modify should not be in META-INF/context.xml; they should be in
${CATALINA_BASE}/conf/[enginename]/[hostname]/[appname].xml where they
are easy for the deployer to get at without digging in the
app. itself. I can't think of anything I would want to put in
META-INF/context.xml, really. The developer doesn't need that layer
of mapping; he knows where all the internal bits are and what they are
called, because he decrees them.
Keeping the Context descriptor outside of the app. means that it won't
be replaced when you deploy a new release (provided that you don't put
the app. in appBase). That's why I do it.
> Without getting into the pros and cons of your first paragraph (which places all responsibility for managing app preferences on the developer), would you agree that the current approach (leaving the context.xml file in the web app) is not fulfilling one of its intended purposes, which is allowing the deployer to customize the application behavior?
I would. I suspect that what people had in mind was that some
installer program would automagically customize META-INF/context.xml,
so that the app. actually deployed is not quite the app. which is
shipped. I happen to think that 'tar', 'unzip', and 'cp' are the
three best installers out there, and would rather put my per-instance
settings somewhere outside the app. altogether. I very much
appreciate the way that Tomcat makes that possible.
I'm not sure what you mean by "places all responsibilities for
managing app preferences on the developer". I thought that this
division requires that the developer *not* manage preferences, which I
take to be deployment details such as "where's my database?" or
"what's the name of this business?" Those are the responsibility of
the deployer; the developer is responsible for supplying values which
are invariant across instances, but which might be convenient to
gather into a .properties or some such.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Machines should not be friendly. Machines should be obedient.
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
Posted by Jesse Barnum <js...@360works.com>.
On May 7, 2013, at 9:40 AM, "Mark H. Wood" <mw...@IUPUI.Edu> wrote:
> Well, the developer can simply pack into the app. whatever internal
> configuration is needed, since he has ready access to the interior of
> the app and can deposit on the classpath *.properties, *.xml, or
> anything else he wants. He can have no certain knowledge of the app's
> runtime environment and should not assume, only specify requirements,
> and provide sensible defaults when there are some.
>
> The deployer, OTOH, has ready access to the app's environment,
> including its Context, but should not be assumed to have such access
> to the interior of the app.
>
> So this division of labor depends on the developer's discipline in
> distinguishing internal vs. external configuration and coding the
> app. to look in the proper place for each. I don't see a good way for
> the container to make up for incorrect design in this area.
>
> --
> Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
> Machines should not be friendly. Machines should be obedient.
Mark, can you give me an example of a use case where it is useful for the deployer to modify parameter values in the META-INF/context.xml file? Assume that at some point, a new version of the application will be deployed, and also assume that the deployer does not wish to re-apply the same customizations with each release.
Without getting into the pros and cons of your first paragraph (which places all responsibility for managing app preferences on the developer), would you agree that the current approach (leaving the context.xml file in the web app) is not fulfilling one of its intended purposes, which is allowing the deployer to customize the application behavior?
--Jesse Barnum, President, 360Works
http://www.360works.com
Re: Why is context.xml no longer copied to
Catalina/localhost/myapp.xml?
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Tue, May 07, 2013 at 04:45:39PM +0000, Jeffrey Janner wrote:
> > -----Original Message-----
> > From: Mark H. Wood [mailto:mwood@IUPUI.Edu]
> > Sent: Tuesday, May 07, 2013 8:41 AM
> > To: users@tomcat.apache.org
> > Subject: Re: Why is context.xml no longer copied to
> > Catalina/localhost/myapp.xml?
> >
> > On Mon, May 06, 2013 at 04:35:19PM -0400, Jesse Barnum wrote:
> > [snip]
> > > 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.
> >
> > Well, the developer can simply pack into the app. whatever internal
> > configuration is needed, since he has ready access to the interior of
> > the app and can deposit on the classpath *.properties, *.xml, or
> > anything else he wants. He can have no certain knowledge of the app's
> > runtime environment and should not assume, only specify requirements,
> > and provide sensible defaults when there are some.
> >
> > The deployer, OTOH, has ready access to the app's environment,
> > including its Context, but should not be assumed to have such access to
> > the interior of the app.
> >
> > So this division of labor depends on the developer's discipline in
> > distinguishing internal vs. external configuration and coding the app.
> > to look in the proper place for each. I don't see a good way for the
> > container to make up for incorrect design in this area.
> >
>
> That's perpetual dilemma for those of us who develop our apps for commercial distribution.
> We usually don't have access to a lot of needed information about the deployment environment, and really don't want to know that much.
> We don't normally have things like machine names, database names, schema names and passwords, etc., and our customers are usually reluctant to provide that information to us, at least prior to on-site install (if there is one). So that sort of stuff has to be in a location that it is relatively easy to point the SysAdmin towards and tell him what should be modified (or done via an install script, where possible).
> And in any case, I don't want to have to modify several hundred context.xml or properties files, etc. and then generate individual war files for each customer. I already have my hands full just creating the half-dozen variations of our product each release.
Exactly my point. You shouldn't have to concern yourself with
instance details; those are the customer's concern, and the most
contact you should have with them is in the case that you want to
provide a wizard to write the instance configuration for the customer.
The customer only needs to know what the variables mean, in terms of
his operation, and how they are named.
${CATALINA_BASE}/conf/[enginename]/[hostname]/[appname].xml is easy to
find and should contain almost entirely only stuff that the customer
might need to adjust. Things the customer isn't concerned with
shouldn't be in there, outside of a couple of necessary attributes of
the <Context> element itself. You can supply a wizard to write it, if
need be.
If you want to do it all for the customer, you can ship a standard,
uncustomized WAR and a small file (perhaps a Context descriptor file)
with all the custom settings in it. You could probably build a Web
page to write the customizations file from a form and download it, if
the customers would accept that.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Machines should not be friendly. Machines should be obedient.
RE: Why is context.xml no longer copied to
Catalina/localhost/myapp.xml?
Posted by Jeffrey Janner <Je...@PolyDyne.com>.
> -----Original Message-----
> From: Mark H. Wood [mailto:mwood@IUPUI.Edu]
> Sent: Tuesday, May 07, 2013 8:41 AM
> To: users@tomcat.apache.org
> Subject: Re: Why is context.xml no longer copied to
> Catalina/localhost/myapp.xml?
>
> On Mon, May 06, 2013 at 04:35:19PM -0400, Jesse Barnum wrote:
> [snip]
> > 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.
>
> Well, the developer can simply pack into the app. whatever internal
> configuration is needed, since he has ready access to the interior of
> the app and can deposit on the classpath *.properties, *.xml, or
> anything else he wants. He can have no certain knowledge of the app's
> runtime environment and should not assume, only specify requirements,
> and provide sensible defaults when there are some.
>
> The deployer, OTOH, has ready access to the app's environment,
> including its Context, but should not be assumed to have such access to
> the interior of the app.
>
> So this division of labor depends on the developer's discipline in
> distinguishing internal vs. external configuration and coding the app.
> to look in the proper place for each. I don't see a good way for the
> container to make up for incorrect design in this area.
>
That's perpetual dilemma for those of us who develop our apps for commercial distribution.
We usually don't have access to a lot of needed information about the deployment environment, and really don't want to know that much.
We don't normally have things like machine names, database names, schema names and passwords, etc., and our customers are usually reluctant to provide that information to us, at least prior to on-site install (if there is one). So that sort of stuff has to be in a location that it is relatively easy to point the SysAdmin towards and tell him what should be modified (or done via an install script, where possible).
And in any case, I don't want to have to modify several hundred context.xml or properties files, etc. and then generate individual war files for each customer. I already have my hands full just creating the half-dozen variations of our product each release.
Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Why is context.xml no longer copied to
Catalina/localhost/myapp.xml?
Posted by "Mark H. Wood" <mw...@IUPUI.Edu>.
On Mon, May 06, 2013 at 04:35:19PM -0400, Jesse Barnum wrote:
[snip]
> 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.
Well, the developer can simply pack into the app. whatever internal
configuration is needed, since he has ready access to the interior of
the app and can deposit on the classpath *.properties, *.xml, or
anything else he wants. He can have no certain knowledge of the app's
runtime environment and should not assume, only specify requirements,
and provide sensible defaults when there are some.
The deployer, OTOH, has ready access to the app's environment,
including its Context, but should not be assumed to have such access
to the interior of the app.
So this division of labor depends on the developer's discipline in
distinguishing internal vs. external configuration and coding the
app. to look in the proper place for each. I don't see a good way for
the container to make up for incorrect design in this area.
--
Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu
Machines should not be friendly. Machines should be obedient.
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
Posted by Jesse Barnum <js...@360works.com>.
On May 6, 2013, at 1:55 PM, Mark Thomas <ma...@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.
--Jesse Barnum, President, 360Works
http://www.360works.com
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
Posted by Mark Thomas <ma...@apache.org>.
On 06/05/2013 16:08, Jesse Barnum wrote:
>
>>> If that's true, then why is the context.xml file no longer
>>> extracted in Tomcat 7? Leaving it in the application directory
>>> means that it's going to be overwritten (losing those
>>> customizations) every time the server admin redeploys my
>>> application, right? Doesn't that seem like a bad idea? Am I
>>> missing something?
>>
>> Not everyone agrees with that view:
>> http://tomcat.markmail.org/thread/snyk3c23zurz5lnq
>
> Mark, thanks for pointing me to that discussion thread - at least I
> understand now the rationale behind the copyXML attribute. I don't
> agree at all that it's default value is false instead of true.
>
> So to summarize, there are two conflicting problems:
>
> * An old extracted XML file that happens to have the same name as a
> newly deployed web application could cause problems and prevent that
> new application from deploying correctly, thus arguing for not
> extracting the context.xml from the web app (copyXML=false).
>
> * If a user customizes the XML file (inside the web app folder), then
> all of their customizations are irretrievably overwritten whenever a
> new version of the application is deployed, thus arguing for storing
> the context.xml in a separate folder and not overwriting it
> (copyXML=true).
You are missing the main argument for this change. Apps that ship *with*
configuration in context.xml packaged in the WAR need to be able to
update this configuration with a new version of the application.
> The current behavior (copyXML=false) is like the equivalent of losing
> your preferences in a desktop app every time you install an updated
> version. It seems self-evident that this is a Bad Thing.
That depends entirely on the use case.
> Many users of my application are directly interacting with Tomcat for
> the first time. While I can put all sorts of comments in my
> context.xml file instructing them on how to modify it, it's difficult
> to explain to them how (and why) to find the right spot in the
> server.xml file to change that attribute.
>
> Is there any point in filing a bug report to request that this
> attribute default to true? Or is it a done deal?
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
Posted by Jesse Barnum <js...@360works.com>.
>> If that's true, then why is the context.xml file no longer extracted
>> in Tomcat 7? Leaving it in the application directory means that it's
>> going to be overwritten (losing those customizations) every time the
>> server admin redeploys my application, right? Doesn't that seem like
>> a bad idea? Am I missing something?
>
> Not everyone agrees with that view:
> http://tomcat.markmail.org/thread/snyk3c23zurz5lnq
Mark, thanks for pointing me to that discussion thread - at least I understand now the rationale behind the copyXML attribute. I don't agree at all that it's default value is false instead of true.
So to summarize, there are two conflicting problems:
* An old extracted XML file that happens to have the same name as a newly deployed web application could cause problems and prevent that new application from deploying correctly, thus arguing for not extracting the context.xml from the web app (copyXML=false).
* If a user customizes the XML file (inside the web app folder), then all of their customizations are irretrievably overwritten whenever a new version of the application is deployed, thus arguing for storing the context.xml in a separate folder and not overwriting it (copyXML=true).
The current behavior (copyXML=false) is like the equivalent of losing your preferences in a desktop app every time you install an updated version. It seems self-evident that this is a Bad Thing.
Many users of my application are directly interacting with Tomcat for the first time. While I can put all sorts of comments in my context.xml file instructing them on how to modify it, it's difficult to explain to them how (and why) to find the right spot in the server.xml file to change that attribute.
Is there any point in filing a bug report to request that this attribute default to true? Or is it a done deal?
--Jesse Barnum, President, 360Works
http://www.360works.com
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
Posted by Mark Thomas <ma...@apache.org>.
On 05/05/2013 16:56, Jesse Barnum wrote:
> I thought that the purpose of having <Parameter> elements in the
> context.xml file was so that end users and server administrators
> could easily customize the application behavior of a deployed
> application.
Correct.
> If that's true, then why is the context.xml file no longer extracted
> in Tomcat 7? Leaving it in the application directory means that it's
> going to be overwritten (losing those customizations) every time the
> server admin redeploys my application, right? Doesn't that seem like
> a bad idea? Am I missing something?
Not everyone agrees with that view:
http://tomcat.markmail.org/thread/snyk3c23zurz5lnq
> I know that I write a set of instructions for my customers to modify
> their server.xml and add the copyXML attribute to revert back to
> Tomcat 6 behavior, but why? Why not leave the default behavior the
> way it was before, so that context.xml files can be customized
> separately from the deployed application? I couldn't find any bug
> report / RFE in the Tomcat bug database explaining why this change
> was necessary or beneficial.
http://tomcat.markmail.org/thread/snyk3c23zurz5lnq
https://issues.apache.org/bugzilla/show_bug.cgi?id=48662
There is also an outstanding question of whether extracted context.xml
files are handled correctly.
http://tomcat.markmail.org/thread/yhmn6rmuv74jfhzc
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org