Re: Deploy a webap to multiple environments (test, pre-prod, prod)

[Charles N. Harvey III]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]