On a related note. About a month or two ago I started work on a patch for lein-ring so you'd have more control over the web.xml that is generated. This was motivated by the desire to use the container's datasource instead of creating one yourself. If anyone is interested I can finish this up and contact weavejester to see if it's something worth incorporating.
https://github.com/mefesto/lein-ring/commit/3016142e1c7aadc77d273453e04f9196319406a2 Allen On Mon, May 23, 2011 at 7:43 PM, Allen Johnson <akjohnso...@gmail.com> wrote: > I'm also interested in this topic. It was discussed briefly on the > clojure-web-dev mailing list a little while ago. What I've been doing > is something like this: > > # lein ring project > myapp/ > config/ > production/WEB-INF/myapp.properties > development/WEB-INF/myapp.properties > test/WEB-INF/myapp.properties > src/ > project.clj > > $ # create war file > $ lein ring uberwar > > $ # update configuration for production > $ jar uvf myapp.war -C config/production . > > $ # or... update configuration for development server > $ jar uvf myapp.war -C config/development . > > This assumes you have a ServletContextListener or equivalent in place > to read on deployment. > > This is quick and dirty. I'd definitely like to see something better emerge. > > Allen > > On Mon, May 23, 2011 at 3:59 PM, Shantanu Kumar > <kumar.shant...@gmail.com> wrote: >> 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 > -- 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
