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
