Brett, thanks for the answer. Tough, I think I should expain myself better ... see below
----- Original Message ----- From: "Brett Porter" <[EMAIL PROTECTED]> > I ensure all differences are externalised from the WAR file. For the appservers > we use (resin, tomcat), anything in web.xml can be put outside the webapp and > added to it (<Context> definition in server.xml, <web-app in resin.conf). So > configuration goes into JNDI environment entries, context-params, resources, etc. Alas, my own personal little experience tells me that there will be, at some point some practical reason (as there always seems to be in projects, since nobody's perfect, or some reason forces us to do so) which forces us to have to build several different WAR files for the different platforms. > For situations where you need to have whole different versions of config files, > the webapp bundles a stage and live version (for dev we copy in whatever suits > as part of the build - as long as the deployed version = live). An example is > log4j-quiet.xml and log4j-verbose.xml. A context-param is then set to say which > one to select. May I insist to say that I doubt (but maybe shouldn't I?) that this scenario is always possible ? For example, if you use Hibernate, you can end up having 40 mapping files, with, in each file, an attribute of the <class> element set to schema="DEV_SCHEMA". ( for information, this is necessary with Hibernate since if you're using sequence based id generators, the global schema value is not inherited. I know this is a bug, but I will not stop using hibernate for that reason). It seems very awkward to maintain 40 x Number of configurations files, and let a context param parameterize the whole think by the means of a custom hibernate mappings loadings class (and if you're using an intermediary framework to load the hibernate mappings for you, it then becomes quite impossible to achieve). This is just ony one of those scenarios where I see that the solution you provided above does not fill well. So, I don't think the problem can not be solved by "arrange yourself not to be in such a situation", alas. So I repeat my question : if you have to build several different wars for the same maven project (for some reason of another), what are the techniques you use that work for you ? Or maybe I am the very only person which has ever faced this situation ? > (If you are actually using log4j, I recommend the log4j sandbox stuff for web > applications). I know this is OT, but what in the log4j sandbox is so great that you recommend me to use a non released of the product ? Please don't feel aggressed by my tone, if so, this is not my intention. I'm just willing to clearly understand the problem. -- Laurent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
