> 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 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 > > -- > 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
