> -----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
