This is a generic Java question. It doesn't matter if you use Maven or, for instance, Ant to build your Java EE app.
Read the properties file from class path. Then make sure that the properties file is on the class path in the container (but outside of the ear), in each environment. In JBoss for instance, one way is to put the properties file in the conf folder. However, you could also read config values from JNDI. Then make sure that the JNDI tree is populated correctly for each environment. /Anders On Fri, Nov 20, 2009 at 01:32, Sony Antony <[email protected]> wrote: > I was thinking of exactly teh same when I wrote it ( the name of the > particular config file to be chosen is stored in JNDI. Using the > application > event listener, teh particular file is preread when app comes online ) > > But I wanted to ask if this is really how most well maintained projects do > it ? > > Does maven have any tricks/standard way to deploy teh config file ? > --sony > > > > > On Thu, Nov 19, 2009 at 7:28 PM, Jesse Farinacci <[email protected]> wrote: > > > Sounds like a job for JNDI. > > > > On Thu, Nov 19, 2009 at 7:23 PM, Sony Antony <[email protected]> > > wrote: > > > Reading the following thread brings forth this question ( Actually > there > > was > > > a thread on this few weeks back. But it wasnt very detailed ) : > > > > > > We have this configuration file that contains machine/server specific > > > information. > > > Assuming my application is an ear, how do I do a build so that I dont > > have > > > to do a build specific for each target hosts. > > > 1. Should I bundle up the configuration file inside the ear file ? > > > 2. Should I bundle up all configuration files for all possible servers > > and > > > at deployment time set some kind of variable ( through teh app server > > admin > > > console ), which resolves to a specific config file ? > > > > > > In general what is teh best practice for this > > > --sony > > > > > > > -Jesse > > > > -- > > There are 10 types of people in this world, those > > that can read binary and those that can not. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
