Re: Passing environment configuration parameters to a Clojure web app
The DTD/schema for web.xml files is not small (e.g. http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd). Rather than offering a transliteration of a subset of web.xml's elements into sexprs, perhaps it would be better to be able to control your web.xml directly, and have lein-ring use it when it's present rather than generating one. Just a thought from the suffering equine department. :-) - Chas On May 23, 2011, at 8:48 PM, Allen Johnson wrote: 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
Re: Passing environment configuration parameters to a Clojure web app
The DTD/schema for web.xml files is not small (e.g. http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd). Rather than offering a transliteration of a subset of web.xml's elements into sexprs, perhaps it would be better to be able to control your web.xml directly, and have lein-ring use it when it's present rather than generating one. Much better idea :) Allen Just a thought from the suffering equine department. :-) - Chas On May 23, 2011, at 8:48 PM, Allen Johnson wrote: 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
Re: Passing environment configuration parameters to a Clojure web app
2011/5/23 Chas Emerick cemer...@snowtide.com:
On May 23, 2011, at 3:48 AM, Laurent PETIT wrote:
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.
That's about right — though of course you don't need to be using JNDI if
you're willing to configure each parameter separately as a system property or
servlet init param.
Well, passing parameters as system properties is out of scope as far
as I'm concerned: for example, it prevents the ability to deploy the
same webapp twice on the same container.
And it requires you to tweak the starting script of the servlet
container, and this thought makes me cringe.
As far as servlet init params are concerned I see this just as a
detail of the first general solution I described: bundle/repackage
your webapp for the target servlet container instance, where
repackaging would mean, probably, a custom version of web.xml.
Beyond that, ring is quite container-agnostic (to the point where you don't
necessarily need to use a servlet container to deploy ring apps), whereas
configuration mechanisms are likely to be container-specific.
Since the extra classpath entries per deployed webapp trick is not
(AFAIK) normalized in JEE, sadly, yes.
For the record, here is what I've come up with, for my particular
application : I'm leveraging this extra-classpath entry trick
of Tomcat, and in my server_info.clj namespace, I have something like
this:
;; server_info.clj
(try
(load server_data)
(catch Exception e
(warn ... explanation ... no specific configuration file found in
classpath ... will use default values instead ..)))
(defonce data1 { ... }) ;; innocuous value, maybe only relevant to dev
environment as a default
(defonce data2 { ... }) ;; defonce used to make sure that if the value
is set in server_data, it's not overriden
And it's up to the operations team to provide, in a way or another
;; server_data.clj
(def data1 { ... })
(def data2 { ... })
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
Re: Passing environment configuration parameters to a Clojure web app
2011/5/23 Shantanu Kumar kumar.shant...@gmail.com: 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. Indeed. So this falls in the category of specific wars for specific target server instance, if I understand correctly. 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
Re: Passing environment configuration parameters to a Clojure web app
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
Re: Passing environment configuration parameters to a Clojure web app
On May 23, 2011, at 3:48 AM, Laurent PETIT wrote: 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. That's about right — though of course you don't need to be using JNDI if you're willing to configure each parameter separately as a system property or servlet init param. Beyond that, ring is quite container-agnostic (to the point where you don't necessarily need to use a servlet container to deploy ring apps), whereas configuration mechanisms are likely to be container-specific. - Chas -- 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
Re: Passing environment configuration parameters to a Clojure web app
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
Re: Passing environment configuration parameters to a Clojure web app
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
Re: Passing environment configuration parameters to a Clojure web app
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. I noticed this: http://j.mp/l5vsjS -- looks like it suits the workflow you described. Regards, Shantanu -- 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
Re: Passing environment configuration parameters to a Clojure web app
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
Re: Passing environment configuration parameters to a Clojure web app
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
Passing environment configuration parameters to a Clojure web app
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
