Women in Technology

Hear us Roar



Article:
  Advanced Configuration of the Spring MVC Framework
Subject:   Synchronizing Bean Properties
Date:   2006-03-23 12:18:14
From:   mariuss
By moving configuration parameters out of applicationContext.xml into a Java properties file you definitely simplify the problem, but you are not solving it. You just moved the problem as well.


In practice you will have to manage several of these properties file and they will tend to be fairly complex. As your application evolves these properties files change as well, and maintaining them on all depoloyment locations is hard.


One solution that worked for me was to keep track of these different configuration file sets in the revision control system as well and the build script will take as a parameter the configuration you want to use (or the target deployment machine).

Main Topics Oldest First

Showing messages 1 through 1 of 1.

  • Single point of configuration
    2006-03-24 02:24:36  Andrew_Sazonov [View]

    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.


    Best regards,

    Andrew Sazonov

    SoftAMIS

    http://www.soft-amis.com