Lift

If you want to provide a configuration file for a subset of your application or for a specifig environment, Lift expects configuration files to be named in a manner relating to the context in which they are being used. The standard name format is: modeName.userName.hostName.props

The first configuration found is used. The order is:

/props/modeName.userName.hostName.props
/props/modeName.userName.props
/props/modeName.hostName.props
/props/modeName.default.props
/modeName.userName.hostName.props
/modeName.userName.props
/modeName.hostName.props
/modeName.default.props

modeName can be one of “test”, “staging”, “production”, “pilot” or “profile”. If the current run mode is development it is ommitted. As you may note, the mode names are those of Run Modes and are accordingly picked by a Lift app depending upon its run mode. The standard Lift properties file extension is props.

Take note there exists no modeName development, as development is assumed to be default (and so ommited). This means that development.default.props or development.foo.props are not valid props names. Use default.props and foo.props instead.

Examples for user myself and hostname mymachine:

No run.mode is given (and so is development)

/props/myself.mymachine.props
/props/myself.props
/props/mymachine.props
/props/default.props
/myself.mymachine.props
/myself.props
/mymachine.props
/default.props

If run.mode is production (with -Drun.mode=production)

/props/production.myself.mymachine.props
/props/production.myself.props
/props/production.mymachine.props
/props/production.default.props
/production.myself.mymachine.props
/production.myself.props
/production.mymachine.props
/production.default.props

The search for the properties files are with respect to the classpath. SBT, at least, takes care of that for you. If you’re running an external tool such as the ScalaTest test runner, you need to make sure the resources directory is in your classpath.

Note if you are running Lift in Jetty, Jetty’s resource directory is by default on the classpath. So, if Lift can’t find a properties file within your jar it will look for one within the resource directory. This has the handy consequence: if you keep your production production properties file out of war file, then you can drop it into the jetty/resource directory, you can then edit it without having to rebuild the war. However, this is a bit risky, as if someone unwittingly then adds, say, a ‘template’ production properties file into the war, Lift will use that one rather than the one in jetty/resources.