Re: Deploy a webap to multiple environments (test, pre-prod, prod)
Very good pointers, thanks a lot ! - Original Message - From: "Tim Shadel" <[EMAIL PROTECTED]> To: "Maven Users List" <[EMAIL PROTECTED]> Sent: Thursday, June 10, 2004 8:21 PM Subject: Re: Deploy a webap to multiple environments (test, pre-prod, prod) > Have you looked through Vincent Massol's slides here? > > http://www.pivolis.com/pdf/Enterprise_Builds_V1.0.pdf > > http://www.pivolis.com/pdf/J2EE_projects_Maven_V1.1.pdf > > http://www.pivolis.com/pdf/Distributed_Agile_V1.0.pdf > > --Tim > > Laurent PETIT wrote: > > >Hello, > > > >I recently read a thread about this subject, but was not entirely convinced > >by the answer. > > > >I think this is a very common problem : you develop a webapp, and you have > >to deploy it on multiple configurations : generally one for each > >test-process environment : internal ( integration server ), in > >pre-production on the client network, and eventually in production on the > >client network. > > > >It is common that you then have to setup different levels for logs, > >different database schema names, different pathnames, ... generally in some > >well identified properties files. > > > >I saw an answer to this problem, which was to setup multiple anemic maven > >projects which will hold the properties differences. > > > > > >I'm not sure this is a "recommended best practice" for the problem ? > > > >What do you folks think about it ? > > > >What do you do in your own projects ? (even if it is not as "a beautiful > >solution" as it should be, what does *work* for you ?) > > > >Thanks in advance, > > > > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Deploy a webap to multiple environments (test, pre-prod, prod)
Have you looked through Vincent Massol's slides here? http://www.pivolis.com/pdf/Enterprise_Builds_V1.0.pdf http://www.pivolis.com/pdf/J2EE_projects_Maven_V1.1.pdf http://www.pivolis.com/pdf/Distributed_Agile_V1.0.pdf --Tim Laurent PETIT wrote: Hello, I recently read a thread about this subject, but was not entirely convinced by the answer. I think this is a very common problem : you develop a webapp, and you have to deploy it on multiple configurations : generally one for each test-process environment : internal ( integration server ), in pre-production on the client network, and eventually in production on the client network. It is common that you then have to setup different levels for logs, different database schema names, different pathnames, ... generally in some well identified properties files. I saw an answer to this problem, which was to setup multiple anemic maven projects which will hold the properties differences. I'm not sure this is a "recommended best practice" for the problem ? What do you folks think about it ? What do you do in your own projects ? (even if it is not as "a beautiful solution" as it should be, what does *work* for you ?) Thanks in advance, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deploy a webap to multiple environments (test, pre-prod, prod)
Hi Carlos, Here's the technique I currently use: Using default overrides from ${target}.properties The ant:copy task illustrates how you expand all of the ${...} expressions in the files included in the specified ant:fileset by using the expandproperties filterchain. Simply supply appropriate values for all the elipses (...). You can then make expand-properties a prereq for you goal that builds your artifact. As a bonus, if you specify a value for target and there is no ${target}.properties file (perhaps you fat-fingered the keyboard), the build will fail and Maven reports that the file doesn't exist. I hope that helps. Cheers, Chuck > -Original Message- > From: Carlos Sanchez [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 10, 2004 2:08 PM > To: 'Maven Users List' > Subject: RE: Deploy a webap to multiple environments (test, pre-prod, > prod) > > > Hi Chuck, > > I suppose you do points 3 and 4 with jelly script in maven.xml. Could you > send an example? ;) > > Thanks > > > Carlos Sanchez > A Coruña, Spain > > Oness Project > http://oness.sourceforge.net > > > > -Original Message- > > From: Chuck Daniels [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 10, 2004 11:06 AM > > To: Maven Users List > > Subject: RE: Deploy a webap to multiple environments (test, > > pre-prod, prod) > > > > This is also a question I've been meaning to ask because I > > don't know if the technique I use is reasonable. Anyway, > > here's what I do to create distributions for various target servers: > > > > 1. Parameterize the various settings in my various > > configuration files that are target-dependent. For example, > > let's say that my logging configuration file specifies the > > log level for a particular component. When I build for my > > local environment I may want this level set to DEBUG, but for > > a production environment I may want this level set to ERROR. > > Therefore, I might have an expression like ${log.xyz.level} > > (where xyz is the log > > component) in my parameterized logging configuration file template. > > > > 2. For each target environment, I create a distinct > > properties file. These properties files can be named > > logically (e.g., test.properties, production.properties, > > etc.) or named for specific machines (e.g., abc.properties, > > xyz.properties, etc. -- where abc and xyz are machine names), > > whatever you prefer. I also create a localhost.properties > > file, which contains properties values I want to use when > > running things locally. > > Further, I create a default.properties, which contains a > > default value for every property I have defined for > > substitution, so that I don't have to define every property > > in all of the other properties files. So, continuing with > > the example, I might have log.xyz.level=DEBUG in my > > localhost.properties file, but log.xyz.level=ERROR in my > > production.properties file. > > > > 3. In my build file, I load properties from > > default.properties first. Then I check the value of the > > property named 'target'. If 'target' has no value, I default > > it to localhost. Then I load properties from > > ${target}.properties, overriding values from > > default.properties. To build for a target other than > > localhost, I just specify -Dtarget=xxx on the command line > > (e.g., -Dtarget=production), where xxx is some target server > > (meaning I must have an xxx.properties file). > > > > 4. Finally, I filter copy all of my parameterized > > configuration file templates so that my ${...} expressions > > get substituted with the property values I have loaded > > (default.properties and ${target}.properties). The files > > resulting from the filter copying are what I then include in my build. > > > > I hope that makes sense. At present, I keep all of these > > properties files at the root of my project (alongside > > build.properties and project.properties), but perhaps there's > > a better place for them. Please feel free to comment on my > > approach, as this is something I concocted on my own. I am > > certainly open to adjustments and alternatives. > > > > Cheers, > > Chuck > > > > > -Original Message- > > > From: Laurent PETIT [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, June 10, 2004 7:21 AM > > > To: Maven Users List > >
RE: Deploy a webap to multiple environments (test, pre-prod, prod)
Hi Chuck, I suppose you do points 3 and 4 with jelly script in maven.xml. Could you send an example? ;) Thanks Carlos Sanchez A Coruña, Spain Oness Project http://oness.sourceforge.net > -Original Message- > From: Chuck Daniels [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 10, 2004 11:06 AM > To: Maven Users List > Subject: RE: Deploy a webap to multiple environments (test, > pre-prod, prod) > > This is also a question I've been meaning to ask because I > don't know if the technique I use is reasonable. Anyway, > here's what I do to create distributions for various target servers: > > 1. Parameterize the various settings in my various > configuration files that are target-dependent. For example, > let's say that my logging configuration file specifies the > log level for a particular component. When I build for my > local environment I may want this level set to DEBUG, but for > a production environment I may want this level set to ERROR. > Therefore, I might have an expression like ${log.xyz.level} > (where xyz is the log > component) in my parameterized logging configuration file template. > > 2. For each target environment, I create a distinct > properties file. These properties files can be named > logically (e.g., test.properties, production.properties, > etc.) or named for specific machines (e.g., abc.properties, > xyz.properties, etc. -- where abc and xyz are machine names), > whatever you prefer. I also create a localhost.properties > file, which contains properties values I want to use when > running things locally. > Further, I create a default.properties, which contains a > default value for every property I have defined for > substitution, so that I don't have to define every property > in all of the other properties files. So, continuing with > the example, I might have log.xyz.level=DEBUG in my > localhost.properties file, but log.xyz.level=ERROR in my > production.properties file. > > 3. In my build file, I load properties from > default.properties first. Then I check the value of the > property named 'target'. If 'target' has no value, I default > it to localhost. Then I load properties from > ${target}.properties, overriding values from > default.properties. To build for a target other than > localhost, I just specify -Dtarget=xxx on the command line > (e.g., -Dtarget=production), where xxx is some target server > (meaning I must have an xxx.properties file). > > 4. Finally, I filter copy all of my parameterized > configuration file templates so that my ${...} expressions > get substituted with the property values I have loaded > (default.properties and ${target}.properties). The files > resulting from the filter copying are what I then include in my build. > > I hope that makes sense. At present, I keep all of these > properties files at the root of my project (alongside > build.properties and project.properties), but perhaps there's > a better place for them. Please feel free to comment on my > approach, as this is something I concocted on my own. I am > certainly open to adjustments and alternatives. > > Cheers, > Chuck > > > -Original Message- > > From: Laurent PETIT [mailto:[EMAIL PROTECTED] > > Sent: Thursday, June 10, 2004 7:21 AM > > To: Maven Users List > > Subject: Re: Deploy a webap to multiple environments (test, > pre-prod, > > prod) > > > > > > 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 ( definition in server.xml, > 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 >
Re: Deploy a webap to multiple environments (test, pre-prod, prod)
A lot of people have these issues, so don't feel strange. I see two ways to do this and I think Chuck Daniels covered more in his latest post. 1) Just like you can with Ant, create parametrized variables in different config files. Then work with your maven.xml to ensure that you build different versions of the war file. So, "maven war:dev", "maven war:staging" and "maven war:production" are all goals in your maven.xml file. With each one you point to a different properties file that stores the different values that get put into the parameters that were previously setup. 2) What I personally do is to have multiple config files, like Brett said. I have a log4j-development.properties, log4j-staging.properties. You get the idea. In my tomcat's server.xml I have a context param setup as "lifecycle". Each webapp usually needs a servlet that runs first to do some initialization of variables, like configure log4j. In this servlet you can read the value from the server.xml and configure log4j appropriately. What I also do is set a System.property( "lifecycle", tomcatLifecycle ) that can then be read by any class in my webapp. I don't use Hibernate but I use OJB. I have 40 classes configured but there is the main repository.xml file which sets up which database I am going to talk to. I usually have 3 databases setup, one for each level (dev, stag, prod). I setup 3 connection instances in this file. Each connection uses the same set of files that describes the Class-to-Table relationships. Then, when my webapp goes looking for a connection, I make sure it gets the connection by name. Or, when you first initialize the application, make sure you set the correct connection as the default. So, it can be done. Brett has the right idea, all of this configuration info should be in some kind of JNDI lookup, then it would be more secure and centralized. But that takes effort and planning, and most of us never get around to any of that stuff. :) Charlie Laurent PETIT said the following on 6/10/2004 2:20 AM: 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 ( definition in server.xml, 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 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-
RE: Deploy a webap to multiple environments (test, pre-prod, prod)
This is also a question I've been meaning to ask because I don't know if the technique I use is reasonable. Anyway, here's what I do to create distributions for various target servers: 1. Parameterize the various settings in my various configuration files that are target-dependent. For example, let's say that my logging configuration file specifies the log level for a particular component. When I build for my local environment I may want this level set to DEBUG, but for a production environment I may want this level set to ERROR. Therefore, I might have an expression like ${log.xyz.level} (where xyz is the log component) in my parameterized logging configuration file template. 2. For each target environment, I create a distinct properties file. These properties files can be named logically (e.g., test.properties, production.properties, etc.) or named for specific machines (e.g., abc.properties, xyz.properties, etc. -- where abc and xyz are machine names), whatever you prefer. I also create a localhost.properties file, which contains properties values I want to use when running things locally. Further, I create a default.properties, which contains a default value for every property I have defined for substitution, so that I don't have to define every property in all of the other properties files. So, continuing with the example, I might have log.xyz.level=DEBUG in my localhost.properties file, but log.xyz.level=ERROR in my production.properties file. 3. In my build file, I load properties from default.properties first. Then I check the value of the property named 'target'. If 'target' has no value, I default it to localhost. Then I load properties from ${target}.properties, overriding values from default.properties. To build for a target other than localhost, I just specify -Dtarget=xxx on the command line (e.g., -Dtarget=production), where xxx is some target server (meaning I must have an xxx.properties file). 4. Finally, I filter copy all of my parameterized configuration file templates so that my ${...} expressions get substituted with the property values I have loaded (default.properties and ${target}.properties). The files resulting from the filter copying are what I then include in my build. I hope that makes sense. At present, I keep all of these properties files at the root of my project (alongside build.properties and project.properties), but perhaps there's a better place for them. Please feel free to comment on my approach, as this is something I concocted on my own. I am certainly open to adjustments and alternatives. Cheers, Chuck > -Original Message- > From: Laurent PETIT [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 10, 2004 7:21 AM > To: Maven Users List > Subject: Re: Deploy a webap to multiple environments (test, pre-prod, > prod) > > > 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 ( definition in server.xml, 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 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
Re: Deploy a webap to multiple environments (test, pre-prod, prod)
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 ( definition in server.xml, 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 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]
Re: Deploy a webap to multiple environments (test, pre-prod, prod)
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 ( definition in server.xml, : > Hello, > > I recently read a thread about this subject, but was not entirely convinced > by the answer. > > I think this is a very common problem : you develop a webapp, and you have > to deploy it on multiple configurations : generally one for each > test-process environment : internal ( integration server ), in > pre-production on the client network, and eventually in production on the > client network. > > It is common that you then have to setup different levels for logs, > different database schema names, different pathnames, ... generally in some > well identified properties files. > > I saw an answer to this problem, which was to setup multiple anemic maven > projects which will hold the properties differences. > > > I'm not sure this is a "recommended best practice" for the problem ? > > What do you folks think about it ? > > What do you do in your own projects ? (even if it is not as "a beautiful > solution" as it should be, what does *work* for you ?) > > Thanks in advance, > > -- > Laurent PETIT > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]