On Tue, May 07, 2013 at 04:45:39PM +0000, 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
