A web application usually has at least one configuration file, that contains jdbc configuration and other settings. You can put such file(-s) inside a .war file or outside it. What are the cons and pros of these approaches? What is your approach and why?
+1
A:
Put them inside the war and use some sort of build-profiles (like maven build profiles). That way:
- you have one-step deployment. No manual editing of properties on remote environments.
- you can have different artifacts (war files) for different environments, so the build is still portable, but you don't need to open wars with a ZIP software to modify settings.
The way to implement/use the build profiles depends on your build environment.
Bozho
2010-02-26 13:18:36
Would you go as far as making build profiles for the major types of Spring Security configuration (e.g. LDAP, X509, rdbms, etc.)? What about settings that the customer HAS to supply, like URL contexts, etc. How do handle these?
HDave
2010-09-28 04:03:58
I don't know :) it depends on whether these are used completely in isolation, or they can overlap.
Bozho
2010-09-28 05:33:05
+4
A:
Imho, outside seems the most convenient if you need to deploy the same war in different environments. Like, dev, itt, uat and production. Same build different configurations.
HeDinges
2010-02-26 13:18:38
well, there is a cleverer way to achieve this without reliance on external files and manual editing them on the production server, for example.
Bozho
2010-02-26 13:47:26
@Bozho, well yes there are other ways, but I found this more convenient, and mostly when you have a lot of different server/network architectures to deploy to. It's something you have to assess pragmatically in regard of your organization, to assess what's most flexible and failure proof. It's never a black-white choice.
HeDinges
2010-02-26 13:56:37
I was also doing manual modifications to remote files, but since I implemented maven build profile (takes 1 afternoon), it's much easier. And a better practice.
Bozho
2010-02-26 14:01:17
@Bozho: sometimes you cannot make as many build profiles as environments that your WAR will be deployed to... because there is unlimited number of servers that can use your WAR (e.g. you make app that is deployed on dedicated servers of your customers).
WildWezyr
2010-02-26 14:24:13
On "Same build different configurations" two questions:1) Do you check-in the configuration file to your source control system?2) How does the application know which configuration to use (DEV, TEST, UAT, PROD)?
Dee
2010-08-11 18:59:24
@Dee Well, yes we check them in our vcs. in several directories named by environment PROD/UAT/ITT etc...This allows automatic deployment scripts or deployment teams to deploy the right configuration files for each environment.I don't think the application should actually know which environment it's running in, nor should behave differently per environment.But in general, the configuration files do rarely change for a same environments.
HeDinges
2010-08-12 07:41:20
+1
A:
IMHO the best way is to use flexible approach and allow config to be inside and/or outside WAR (with some extra logic for config lookup order and what file/dir names that config may be kept in).
I have experience with extremely different deploy models/schemas - sometimes it is one build/many configs, other time - even: many builds/one config on one server - strange, but can happen ;-).
This may be especially helpful if you are developing some kind of platform that your customers/users may deploy in custom environments unspecified at WAR build time.
WildWezyr
2010-02-26 14:20:15
why down-vote? what is wrong with my answer? please give info in comment!
WildWezyr
2010-02-26 14:35:49