Channels ▼

JVM Languages

Configuring J2EE Deployment Descriptors

Source Code Accompanies This Article. Download It Now.

Tip #1: Watch Out for Parameterizing

A common tactic many J2EE developers use for addressing configuration issues involves parameters. This may seem practical at first, but you eventually see why it is wrong. When developers are asked to take a working application and parameterize properties and values in files, it means that if a developer has coded a particular property in a file for a log file location with a value of C:\appsdev\efoobar\comm.log, then the developer will create a parameterized version of the same file, where the value has a parameter such as @[email protected]. The strategy then is to replace the parameter with values meaningful to the different target runtime environments; for example, C:\appsqa\efoobar\comm.log for a test server and C:\appsprod\efoobar\comm.log for a production server.

The reason that parameterizing lots of files is popular is that Ant Copy and Replace tasks have a nifty search-and-replace capability for tokens of this type, and it is tempting to make use of this tool in hand. However, additional labor is required to do the parameterization, and it is a risky manual process to eyeball and parameterize every relevant runtime value in a set of files. If one of these values is missed, the error would not be caught until runtime, after the EAR or WAR files have been built and deployed. I have found that at larger J2EE development sites, values that should be parameterized will inevitably occasionally get overlooked, causing a production "down" problem—all because of a small parameter. Your customers will not understand, and see the application as unstable.

In this case, the burden for developers is not trivial—you must now keep track not only of which properties need to be changed for each environment, but also which properties in which files have been parameterized. While there are situations where it may be necessary to go this route, parameterizing property values should be minimized and used for as small a subset of files and parameters as possible. In short, starting out parameterizing everything in sight is a common mistake to watch out for.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.