I introduced a configuration database table for just the reasons you describe, plus one more. Our deployment people want to deploy an EAR file and nothing else. So the config files must be in the EAR and since we cannot modify the EAR that makes them the same in all environments: test, qa, s&p, training, prod, etc. We have quite a few things that must vary in each environment, so those go in the database. It's set up so a configuration file overrides the database. That lets a developer customize his own environment through files without changing a shared database. The configuration module has a lazy cache to improve performance and an administrative dashboard to clear cache and bring in changes.
Any of that sound good?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jan 23, 2004
Thanks very much. Yes, that definitely feels more assuring. Specially the idea of overriging the default properties with a config is very cool.