--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/Pl_nM89StTMJ.
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.
fwiw, the way the underlying https://github.com/typesafehub/config
library is set up should make this unnecessary in most cases.
The basic approach is:
- create a reference.conf containing your default values
- the API throws an exception if a value is not set (which would
normally indicate a broken classpath or deployment)
There are cases where this is awkward (basically, cases where you have
a dynamic config setting e.g. a config key based on some runtime
value) but even in those cases you can arrange to merge the dynamic
config with a static set of defaults up front using withFallback(),
thereby ensuring that all settings have a value.
mySettings.withFallback(defaultSettings)
The fundamental problem with an API like:
Play.configuration.get("myProp", "DefaultValue")
is that "DefaultValue" has to be cut-and-pasted to any location that
gets "myProp". Another problem with it is that people have to read
source code to learn what the default values are, instead of seeing
them all in a reference.conf.
Another case is when you want a config setting to be optional (i.e.
null is a valid setting for it). That is a bit different situation and
then handling null or Option is necessary.
Anyway the README at https://github.com/typesafehub/config and the
examples/ directory for that may be helpful.
Havoc
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
This means play will look for all files. So the sub project layout should work for you out of the box if I understand it correctly.
On Mon, Apr 23, 2012 at 11:32 AM, GrailsDeveloper
<openso...@googlemail.com> wrote:
> Not sure if I really get it. First the methods which are provided by
> https://github.com/typesafehub/config are not accessible for the config.
You can always use Play.current.configuration.underlying
So for example if you wanted to you could do:
val myDefaults = ConfigFactory.parseResources("something.conf")
val myModuleConfig =
Play.current.configuration.underlying.withFallback(myDefaults)
val whatever = myModuleConfig.getString("whatever")
However I'm not sure that is necessary, if you just put a
reference.conf on the classpath I would expect that it works fine. The
key is to be sure it's on the classpath and at a root resource
directory (not inside any Java package).
> So
> with fallback doesn't work. In my case I want to create a submodule which
> should be configurable. Is it correct if I define a reference.conf in the
> submodule conf-folder(?) then I will always get this values except in
> application.conf has different values?
I'm not sure how the conf folder is handled; if it ends up on the
classpath then putting reference.conf in there ought to work. If it
isn't on the classpath you might have to use src/main/resources
instead of the conf folder, or something like that.
Havoc
Hi,
On Mon, Apr 23, 2012 at 11:32 AM, GrailsDeveloper
Havoc
I'm sure there's a way to get to 'underlying' in Java, just a question
of how hacky it is ;-) but yes hopefully you won't need it.Havoc
On Tue, Apr 24, 2012 at 2:27 PM, GrailsDeveloper
This is awesome!I had no ideé it worked that way. thanks!
Should we discard the pull request, and add this to the documentation instead?
To post to this group, send email to play-framework@googlegroups.com.
To unsubscribe from this group, send email to play-framework+unsubscribe@googlegroups.com.