In a Java EE application deployment descriptors are used to configure and setup the application. One major issue is that these deployment descriptors are mostly static. In practice, there's often a need to have a different set of configuration files for different situations.
For instance, for a development environment I might want a link configured by a context-param in web.xml to point to 'localhost:8080/someapp/myresource', while in a QA environment I want it to point to 'qa.mycompany.com/myresource' etc.
As another example, since Java EE 6 a data source can be configured in among others web.xml using the data-source element. Especially in this case there is a pressing need to have different data sources pointing to different databases depending on the context.
Yet another example is a Servlet Filter that provides some development utilities, which should definitely not be activated in a production environment.
A possible solution for this could be the introduction of descriptor fragments that are included from the main descriptor based on a placeholder. E.g. in web.xml:
Inside the WEB-INF/conf directory, multiple folders could be created, each corresponding to a stage, e.g.
Starting up the application with -Dmycompany.staging=dev would then cause WEB-INF/conf/dev/web-fragment.xml to be processed.
Besides being useful for directing different fragment descriptors to be processed, placeholders can also be used to externalize some values completely. E.g. the password in a production datasource:
For the above to be really useful, another concept should be introduced: the ability to load system properties from an external properties file. Specifying the above password via a -D command line option is of course not secure, since it can be seen in the running processes (e.g. using the ps command). Something like the following would be more suitable: