Software developers and quality engineers know that there are certain configuration settings, maintained within web applications and enterprise application archives, that make sense during development, but have absolutely no business being active in production. For example, the facelets.SKIP_COMMENTS and facelets.DEVELOPMENT setting are very helpful when building and troubleshooting an application, but they have a negative impact on performance and even pose a security risk if they are enabled in production.
Using this tip, your applications will run more securely and more efficiently.
It is expected that a developer, or even the build process itself, will change these settings before a web application is packaged for deployment. But what happens if a step in the build process is skipped, or if a developer forgets to make the configuration change? How can an administrator protect their server configuration from an absent-minded developer?
The first step in protecting the sanctity of your application server from such actions is placing a context.xml file in the META-INF folder of the web application archive (WAR) file being deployed, and within the context element of that xml file, add a parameter for each setting that needs to be set permanently on the server.
<parameter name="facelets.DEVELOPMENT" value="true" override="false" />
<parameter name="facelets.SKIP_COMMENTS" value="true" override="false" />
When the application deploys for the first time, these files will be copied to the following location:
The administrator needs to then go into this file and change the context parameters to the values that should will be used indefinitely on the server:
<parameter name="facelets.DEVELOPMENT" value="false" override="false" />
<parameter name="facelets.SKIP_COMMENTS" value="false" override="false" />
Once this is done, Tomcat will not overwrite the setting in these files, and any changes or updates that happen within a newly deployed module will be overridden by the server's settings. No matter what happens in the future, regardless of whether the developer forgets to make a change before deployment, or if something goes awry during the packaging and deployment process, the settings that should be used in production won't be overridden, and your applications will run much more securely, and much more efficiently.
Do you have any good tips that will help administrators save time when configuring the application server?Let us knowabout your favorite tips and tricks.