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.

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:rwhee...@artifact-software.com]
>Sent: Monday, November 22, 2010 1:03 PM
>To: users@maven.apache.org
>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<ilya.may...@ubs.com>:
>>> 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: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>For additional commands, e-mail: users-h...@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to