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
