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
