Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

How to handle project configuration

DZone's Guide to

How to handle project configuration

· Java Zone ·
Free Resource

Take 60 minutes to understand the Power of the Actor Model with "Designing Reactive Systems: The Role Of Actors In Distributed Architecture". Brought to you in partnership with Lightbend.

Every web project needs some environment-specific configurations. Database credentials, root url, smtp settings, to name a few. It’s a recurring question on stackoverflow, and I’ve seen a lot of variations on the topic, and here I’ll describe the one that I think is best.

  • put all such properties in a .properties file (for example application.properties)
  • have that application.properties sitting outside the web application. It is not bundled with the build
  • provide a command-line option that indicates where that file is located. For example -Dconfig.location=/home/you/config
  • on application startup (in a ServletContextListener usually) load the file and put it in a map. Can be java.util.Properties or a HashMap
  • for spring users – use <context:property-placeholder-configurer location="file://${config.location}/application.properties" . Other frameworks will likely have some mechanism for loading such global properties
  • hold a skeleton properties file in the SCM repository. It should contain all properties, but their values are irrelevant – they will change on each environment
  • the ops team is likely to benefit from versioning different environment configurations (production, qa, stage), so a separate /config folder/subproject can be created and all environment-specific properties can be stored there. When adding a property developers should go and update all files accordingly
  • properties that are not dependent on the environment, but are still global for the project, can be stored within the project (src/main/resources for maven), and committed to SCM. They can be merged with the external properties on startup (merged in memory, that is)
  • most of the externalizable properties can have reasonable defaults – the smtp server of the company, the database driver, etc. They can be placed in a application-defeault.properties within the project, and the external file can override them. This is just an option – if you are going to have a file committed in the repository with those reasonable defaults, and each environment to use that file as a basis, it’s virtually the same

Developers can easily run their projects that way. Ops can easily deploy builds on different environments. The build remains environment-agnostic.

 

From http://techblog.bozho.net/?p=483

Learn how the Actor model provides a simple but powerful way to design and implement reactive applications that can distribute work across clusters of cores and servers. Brought to you in partnership with Lightbend.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}