On 22/11/2010 3:38 PM, Haszlakiewicz, Eric wrote:
Well those are some rather useless answers.
JNDI will only "do the job" if you configure it that way. You need to get that
configuration *into* tomcat somehow in the first place, regardless of whether you use
JNDI or a properties file.
I was not suggesting that an unconfigured Tomcat would do JNDI on its own.
The goal is to get the server specific configuration out of development
teams hair and into the operations area.
We started out with bits of server configuration in the applications and
of course, it caused all kinds of silly errors when the wrong things got
deployed to the right place and vice versa.
We moved the server specific files into their own project which has 1
file per server with all the right JNDI for that server.
If you want to make a new server configuration, you just make a new
server configuration file that you deploy to the Tomcat configuration
directory.
Developers do not have to worry about building server specific WAR files
with lots of dancing to get the right setup in the right WAR file or
worrying about deploying the right combination of WAR files.
Reduced our silly deployment errors.
Ron
To suggest some options for the original poster:
There are several different options to choose which configuration gets used
or included in a application package. One way, which I have used a fair
amount, is to include all configurations, and have an environment variable that
you set when you run that app that causes it to choose the right file. The
exact method of doing this depends on exactly how your configuration is stored,
but it might consist of things like having property references in spring config
files, tomcat setenv.sh scripts that pass appropriate java options, or custom
java code within your app that looks for the variable settings.
On the other hand, if you want actual, separate application packages, each that only
contains a single set of configuration options, well then you're back in the realm of how
to get maven to do that for you. What I've done for this is use profiles with embedded
ant tasks that copy the appropriate files into place. Then to build a dev environment
you might do something like "mvn -P dev package". Of course, you can use any
other plugin config within a profile other than the ant plugin, such as having separate
assembler plugin configs and include different configuration files that way.
There's lots of way to do it; I'm not sure what the best one is.
eric
-----Original Message-----
From: Ron Wheeler [mailto:[email protected]]
Sent: Monday, November 22, 2010 1:03 PM
To: [email protected]
Subject: Re: Multiple packages with different configuration files
JNDI will do the job on Tomcat.
Ron
On 22/11/2010 1:47 PM, Antonio Petrelli wrote:
2010/11/22<[email protected]>:
This app need to be packaged with different configuration files (server
names/IP addresses) for Dev/QA/Prod environments.
This kind of info are better put in the server. For example, for
JBoss, you can create a .properties file and put it inside:
<jboss>/server/<yourserver/conf
Everything in the conf directory is available in your classpath.
Antonio
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
