Which do You Prefer: Properties or Environment Entries
J2EE applications, both Web and EJB, often need to set configurable parameters such as a timeout value, retry count, and so on. To avoid hardcoding some arbitrary values for these parameters in code, the applications need to externalize these values so that a deployer can change them without recompiling the code.
The portable solution in J2EE for such configurable parameters is environment entries as specified using
env-entry in the deployment descriptors for a Web or EJB module. Here is an example (from Java BluePrints Adventure Builder Reference application):
However, the same can also be achieved by using properties. Essentially, the developer externalizes these values in a property file, and loads up the properties at runtime. There are issues such as how to portably specify the location of the property file. If the property is not expected to be changed much (so a recompile/repackaging is okay) then the property file can be bundled with the classes, and then it can be portable looked up. If the properties are expected to be modified at deployment time (or later), then it gets tricky since then you need to ensure that the property file is available at a certain location in all deployments.
This is often an annoyance even while developing the application, when more than one developer are working on the codebase, since the filepaths are often different for different developers.
The big advantage of using env-entries is that they are portable, and can be easily changed at the deployment time using the deployment tool provided by the application server. The main advantage of properties is that they are really simple to write, and avoid dealing with the deployment descriptors. It is also possible to write code such that the properties are allowed to change even at runtime.
So, which do you prefer, properties or enviroment entries?