We use a combination of settings methods. Some web settings go in the web.xml in a <context-param> element. Things that are non-web specific go into the Java System Preferences. I was initially skeptical of this one, but it's never given us trouble. We have an Ant task that loads these preferences and then any app can retrieve the values. An overriding goal is that configuration files that need to be changed to work on a given system (e.g. the file with local login/password info) should not be a file you check out from CVS and modify. Instead, a template lives in CVS that you copy to make your system local version.
Having multiple places to set variables can present a challenge, especially if some values have to match. To address that, all of our configuration files have a -template form (e.g. web.xml-template) which has all important values defined as replaceable tokens (e.g. ${hostname}/${context-name}. Our Ant build takes care of the replacements and draws all the values from a single .properties file at build time. We have a default .properties file in CVS that has either safe default values or templates that users can copy and put into a local properties file that overrides anything in the default one. Overall, it has made configuration relatively simple for a new deployment.
Here's the ant task to set up web.xml (package names have been changed to protect the guilty)
<!-- The following two filter sets are referenced in each of the following config targets.
First the build.properties tokens are replaced, then the build.properties.template
tokens are replaced (only if they didn't already exist in build.properties) -->
<filterset begintoken="{" endtoken="}" id="build.propertiesFilter"
description="Used to parse tokens in config files into their associated values in build.properties.">
<filtersfile file="build.properties"/>
</filterset>
<filterset begintoken="{" endtoken="}" id="build.properties.templateFilter"
description="Used to parse tokens in config files into their associated values from build.properties.template.">
<filtersfile file="build.properties.template"/>
</filterset>
<copy overwrite="true" file="${com.somecompany.basedir}/web/WEB-INF/web.xml-template"
tofile="${com.somecompany.basedir}/web/WEB-INF/web.xml">
<filterset refid="build.propertiesFilter" />
<filterset refid="build.properties.templateFilter" />
</copy>
K.C.
Laurent wrote:
Hi,
I have a few settings in my webapp (address of the LDAP server, location of 2 or 3 files), which are in the source code at the moment. This makes it difficult to change them (and I have to recompile every time). Where is the best place to store these kinds of settings? I thought of using a RessourceBundle, what do you think?
Thanks
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
