Hello Laurent, Quite interesting points there. Yes, I agree - having confidential config (production etc.) in code base is not advisable. The reason I mentioned that though, was because I was trying to cover a gamut of workflows the situation may demand. One one extreme there may be a company where no developer gets to touch production servers and must develop for a target config constraint. On the other a set of developers who routinely deploy to production and can get away with changing deployment practices on the fly.
What I would like to emphasize is to distinguish one environment from the other (the code base may contain dummy config data in version control.) A developer can change the dev config to a valid setup, and similarly the person who builds for production deployment can change the config locally (without committing the config details back to the version control) and build a deployable bundle. An added level of indirection (where a config script loads details from either a discoverable or a fixed resource) can bring some flexibility -- the Ops guys can even edit config and re-start the app. Though web container specific and servlet specific solutions are useful for many cases, I am not sure I would recommend that as a general practice -- for example, what am I to do if I have to deploy my code to Netty/Aleph? IMHO ideally a Clojure webapp should be easily buildable/deployable as a WAR (or EAR :-\) for web containers like Tomcat/JBoss etc., but it may not depend on one. How to accomplish such builds where we cherry pick config stuff when building for a certain environment (and how it integrates with the development workflow) is a different aspect. I think I have seen Apache Ant gives sufficient flexibility to do these things. Maybe Leiningen can deliver some of the same things using plugins. Regards, Shantanu On May 23, 12:48 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote: > 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
