Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
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 mw...@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 mw...@iupui.edu
Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
On Tue, May 07, 2013 at 04:45:39PM +, Jeffrey Janner wrote:
-Original Message-
From: Mark H. Wood [mailto:mw...@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 mw...@iupui.edu
Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
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. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient. signature.asc Description: Digital signature
RE: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
-Original Message- From: Mark Thomas [mailto:ma...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
-Original Message- From: Mark H. Wood [mailto:mw...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
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 mw...@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?
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?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
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?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why is context.xml no longer copied to Catalina/localhost/myapp.xml?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
