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