[2.0] application.conf mode specific?

[joergviola]

In play 1.2.* this handy syntax worked: %dev.mail.stmp=mock.
I could not get this to work in 2.0-beta - am I missing something, is
it planned?

[joergviola]

ah and BTW, can I used the ${ENVIRONMENT_VAR} syntax?

[Brian Nesbitt]

I blogged about how I did it in Play 2 here http://nesbot.com/2011/11/22/now-running-on-play-2-beta  about 1/2 way down.

Its not how it will be done once the RC is out, but it worked for me in the mean time.

[peter hausel]

You might want to take a look at this https://github.com/havocp/config since this is library that's used right now (was added after the beta). HTH Peter

[Havoc Pennington]

Hi,

Someone was just asking about this on my blog post:
http://blog.ometer.com/2011/12/09/configuring-the-typesafe-stack/

I was assuming that Play already did this on top of the config lib but
I guess that's wrong and Play 2.0 does not have it (before or after
switching to the config lib).

If Play wanted this feature, it could do something like (not tested):

val modePrefix = "%" + mode
val baseConfig = ConfigFactory.parseFileAnySyntax("application")
val appConfig = if (baseConfig.hasPath(modePrefix)) {
// "lift" the mode-prefixed subtree up to the root, overriding
anything at the root
baseConfig.getConfig(modePrefix).withFallback(baseConfig)
} else {
// return the config unchanged, there are no applicable mode-prefixed keys
baseConfig
}
val finalConfig = ConfigFactory.load(appConfig)

This does imply that anything with a mode prefix would always "win"
over a key in application.conf without a mode prefix, because the mode
prefix subtree falls back to the original root config tree. If that
isn't desirable, something more complex would be necessary. I'm not
sure what Play 1.2 did here in terms of prioritizing if you set
mode-specific and also mode-independent values for the same key.

By doing the mode-prefix-processing on the result of
parseFileAnySyntax (prior to passing it to ConfigFactory.load), system
properties would be added in ConfigFactory.load and would still
override anything from the mode prefixed keys (and you could not use a
mode prefix on system properties). If that isn't desirable, system
properties could be merged first and mode prefix processing could
happen after that.

There are also other ways this could be done no doubt, but an
advantage of the withFallback approach above is that it's all in one
place when creating the initial Config object, you don't have to
modify any other config-using code to know about modes. The above
approach would automatically allow the use of the mode prefix with
Akka etc. as well.

Havoc

[Guillaume Bort]

> This does imply that anything with a mode prefix would always "win"
> over a key in application.conf without a mode prefix, because the mode
> prefix subtree falls back to the original root config tree.

Yes it should work this way. A key defined for a specific environment
must win over a standard key.

Thank you Havoc, this is a great lib!

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>

--
Guillaume Bort