Ok, I see where we misunderstand each other. What you want to do is to build just one war. This war should not include any environment configuration at all! Environment dependent configuration should be handled outside of the war.
One way to do this is to always load config file from the classpath. Every app server/web container (?) provides some conf folder where tou can put your configuration files so that they are added to the classpath. The config file should always be named the same name, regardless of the environment. (How you version control the config files is outside the scope of this discussion. It could be in a scm, in paper form, etc.)) Another way is to read config through JNDI. You follow? /Anders On Tue, Jan 25, 2011 at 13:03, Miguel Almeida <[email protected]>wrote: > Anders, > > I think I understand what you mean, but it doesn't seem to be very > different > from the current approach. > > On Tue, Jan 25, 2011 at 11:35 AM, Anders Hammar <[email protected]> wrote: > > > Antonio is right. > > > > This has been discussed several times. Search the archive for many > examples > > of doing this, including using JNDI or putting a properties file on the > > classpath. > > > > This leads to having, for example, a config-dev.xml, config-prod.xml, > config-clientTest.xml, etc in our code and, if necessary, use a filter to > build only with one of those. I haven't used JNDI much, but it seems more > complex and it might scatter the configuration if you need to put the > configuration outside the app (like in tomcat's configuration file). If one > can use JNDI with a similar approach as before (ie, one config.xml file), > then it's the same case I mentioned. > > > > > I understand this would require changes to your code base. Major changes > > possibly. But it is the right way to go. Once you have donw this, adding > > new > > environments is a small task instead of requiring a new build (and > breaking > > close to everything Maven is about). > > > > What I still am failing to realise is the major problem with putting this > in the profile: building a new environment now is as simple as adding a new > profile in the pom.xml. The only downfall I see is that I now effectively > have eg {log4j.loglevel} in my log4j.properties and the app will fail if I > don't define log4j.loglevel in the properties section of the active > profile. > But that seems to also be the case with any other approach: if I don't > define the string in JNDI it will also not work. > Users in the archive suggest a variety of methods, from JNDI to profiles. > Is > there any other pitfall I'm not seeing? > > > <profile> > > > <id>dev</id> > > > <properties> > > > <isDevelopmentMode>true</isDevelopmentMode> > > > > > > > > > > > > > <hibernate.connection.url>jdbc:postgresql://locahost/develomentDB</hibernate.connection.url> > > > > > <application.uploadPath>/mnt/devel/</application.uploadPath> > > > ... > > > </properties> > > > </profile> > > > > > >
