Hello, Thanks for answering !
My remarks follow: 2011/5/22 Shantanu Kumar <kumar.shant...@gmail.com>: > 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 idea of having production settings in the codebase as "default values" doesn't feel right to me -in general- (and in my particular case). Generally, some of these info are confidential, and their lifecycle does not match the lifecycle of the product. > 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! For what you describe, there are ways (as far as I remember) to manage this with webapps, I think. By placing an HttpFilter/Listener in front of the servlet, etc. (not sure about the details) > 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. Yes, to some extent convention settings can work. But it's not rare to have some intermediate servers (dev's computer, test server) run on e.g. Linux, and sometimes the final server run on Windows. Not to say that this places a strong constraint on the server. I've got some more ideas from friends of mine, one of which seems real interesting : leverage extensions provided by the servlet container (e.g. Tomcat) provider: tomcat provides a way to "extend" the classpath of the webapp via configuration : that way you can put in your externalized context.xml file a "VirtualWebAppLoader" and initialize it to add to the classloader of the webapp the contents of e.g. $catalina_home$/conf/myAppConfig/ directory. From them on, your webapp will be able to see your configuration files in the classpath, even so they're neither in WEB-INF/classes/ nor WEB-INF/libs/ directories. Of course this technique will be limited to those servlet containers which provide similar classpath extension mechanism, so you need to be in control of the potential servlet containers to which your app may be deployed. So far, the "most" general techniques I can see are : either bundle/repackage your webapp for the target servlet container instance, either pass the path to configuration file(s) via one (or more) JNDI parameters. Cheers, -- 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
