||Advanced Configuration of the Spring MVC Framework|
|Subject:||Single point of configuration|
Response to: Synchronizing Bean Properties
Yes, you are absolutely correct - actually, I've used similar approach. These configuration files are stored in version control, but servers were able to retrieve them from one central location. Your solution will work perfectly, but the system I described has some specifics.
It seems that I forgot to mention that we have several servers that execute the same web application and the set of settings that could be configured is identical and in some cases even values of some settings could be the same amoung all (or groups) of servers.
In general, the problem with configuration could be quite a twofold - from the one side, it's necessary to support evolution of the system during the normal system lifecyle (new versions, updates etc) and, from the other side, it's necessary to solve scalability problems - say, have ability to add additional servers to farm without necessity to rebuild/redeploy other servers.
Actually, the last problem was more important for our system, since scalability and dynamic adding of new servers was just a critical requirement.
Initially we simply used properties files stored on shared file system, but as system grows, we created simple server that provides configurations to production servers - and that' s why we don't have to maintain them on deployment locations - we have to maintain only in single central place.
So far this scheme seems to be quite simple to support and maintain and works fine for us.
However, it could be quite a specific for our system and for particular project it's definitely necessary to analyze all requirements carefully to decide which approach is more suitable and should be used.