Where should one put configuration data?

[dcioccar]

Hi all,

from what I understand about Spring, one should be able to reduce the reliance on external (dependancy lookup) type systems such as JNDI, thanks to dependancy injection. This is fine, and I am very happy to move all my object interdependancies into the application context which I deploy with my web application.

My question relates to what to do with other "configuration" type data, such as the name of the database which will be used or the e-mail address which is used for sending e-mails. In several examples, I've seen this in the web application context XML. I don't want this information to exist inside the web application itself, as this would mean that each time a new version was deployed it would need to be reconfigured. As the same WAR will be deployed in many different situations, each requiring a specific configuration, the configuration information must exist outside the web app.

So what are the best options for storing common, environment specific, configuration data which remains the same when the application is upgraded? JNDI? JMX? A table in a database? Simple "properties" files in a common directory (although often web apps can't access files outside the context of the application)? Ideally, I should be able to configure different types of information (datasources, properties, mail servers, etc) via a common interface.

In typical J2EE servers, this functionality is normally provided by JNDI. What would be the most elegant way to address this requirement in a Spring environment?

Thanks,
Dominic.

[jbetancourt]

It depends. What is the life cycle of that data, when is it required, what is the security required, who changes it, is it cluster wide, runtime configurable, and so forth.

For example, if it is the database config data, then it has to exist prior to app boot up, so the simplest thing that would work is file based persistence such as properties or even Preferences.

I'm wondering if configuration data storage can't just be another application of a DAO that Spring abstracts out, just as it does with JNDI. So, it doesn't matter where something is, LDAP, DB, Props, ....