I have wondered about this problem and at the first glance it looked straightforward to me to put moving parts (config elements that could change) into dynamic vars/atoms/refs. The production env can use the default config, and anything else (dev, testing) can alter the default config to override the settings. The dev/testing should have different entry point (may be in "test" directory, as opposed to "src") than the prod version. That said, the config elements themselves can be loaded from certain config files. If it's a web app, you can bundle config in file(s) in WEB-INF and load from there on init -- now that leads to a complicated build process because you cherry pick the config file (for staging, prod or integration test?) for the build target.
Another complexity might arise where the config must be used to carry out certain stateful initialization to be useful to the app. How do you gracefully handle the errors? So we go back to some mutable flag that gives the go-ahead. Ugh! If the config element is common enough (e.g. database coords), it might make sense to go for convention-based settings that remains more or less the same. I have experimented a bit on this here: https://bitbucket.org/kumarshantanu/clj-dbcp/src (jump to the section "Create DataSource from .properties file") - I am interested in knowing what others think about this. Regards, Shantanu On May 23, 12:15 am, Laurent PETIT <laurent.pe...@gmail.com> wrote: > Hum, maybe I should open up the question a little bit ... : > > in the context of deploying a clojure webapp in enterprise, where > generally dev and op teams are different, what is the technique you > use to have different configuration files for different target > environments ? > > 2011/5/20 Laurent PETIT <laurent.pe...@gmail.com>: > > > > > > > > > Hello, > > > I like to have the configuration parameters of my webapps not being > > bundled in resource files in my webapp(*). > > So that my webapp can be packaged once and for all for a given > > version, and not be repackaged for each deployment target. > > > The technique I'm generally using when doing this, which is the most > > agnostic (IMHO) wrt "where" the webapp will run, is to pass via a JNDI > > parameter the absolute path to the configuration file having the > > values relevant to the execution environment. > > > By doing so, the team responsible for managing the webapp has the > > ability to specify where the configuration file should live. > > > For example, if my webapp must call some remote xml-rpc service, then > > the URL of the service will change from environment to environment > > (not the same for testing, pre-production, production, for example). > > > So now my question : is there already somewhere in the ring ecosystem, > > or elsewhere, a package which already provides this as well as perhaps > > other facilities to still enable to painlessly use it in conjunction > > with unit and/or integration testing, etc. ? > > > Thanks in advance, > > > (*) : recent discussions / readings have, tho, somehow started to make > > me doubt about the "dogma" around my approach. For example, currently, > > Amazon Elastik Beanstalk seems to promote uploading wars created > > specifically for a platform (there's not the ability to bootstrap the > > webapp but from its own embedded resources, AFAIK). > > > -- > > Laurent -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
