-
Notifications
You must be signed in to change notification settings - Fork 967
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support or null methods #282
Comments
If the pool artifact provides the defaults then the pool should have its own reference.conf and you put the docs there? |
I just realised - I got this confused with the other issue I raised about prototype objects, so ignore my previous (deleted) comment. The connection pool is third party - BoneCP (soon to move to HikariCP). As much as I'd like them to use Typesafe config, they don't. And there are many similar cases in Play, including async-http-client, jpa, ebean, ehcache, plus the JDK itself, particularly with JSSE, where there are many cases where we want to delegate to the platform default algorithms/ssl providers/etc. |
#186 is the existing issue for OrNull methods. It may also be worth thinking about ways to merge the default config of these other packages into the reference config, in the same way system properties and environment variables are currently merged in. One feature we could have is a way to specify code to run as part of loading defaultReference(). Basically a way to register a Another possible idea could be a tag on |
Merging config is not always possible. For example, often the default is not a configuration item at all, it's an object that has been constructed and initialised by the third party library (eg an There's also situations where the default is not a static value, but something more dynamic. For example, in Play you can specify a router using |
Also something that I was thinking of doing here was writing an sbt plugin that validated Typesafe config configuration to ensure that all the keys that a user has defined were overriding keys in the available |
have you seen the existing checkValid method? or suggesting more than that ? |
I hadn't seen that, but I'm thinking something more comprehensive. |
The router situation sound like a list of FQCNs that will be tried in order, would that solve your situation? |
This is for #186 / #282 and shows one approach only for boolean (if this looks fine, we'd cut-and-paste for the other getters). I used Optional here because it seems likely to be the way of the future and produces a safer API. Because of Optional, this API would be commented out if someone does a Java 7 branch.
aeebeaa shows how this could be done; comments appreciated before I tediously cut-and-paste to every single type, since there are 25-ish types we have getters for. Now that I did that... a much smaller API addition could be |
|
Btw, we've created a type class based API to accessing Typesafe config in Play now, so we can add all sorts of different methods for looking up config (a big one at the moment is looking up deprecated config, falling back to the new config keys, so if the deprecated one is found, it outputs a warning saying that config value is deprecated). |
leaning toward just isNull to avoid the tons of methods but will sleep on it and see if anyone else has ideas in the meantime. |
Proposing PR #286 to close this. |
This is for lightbend#186 / lightbend#282 as an alternative to adding a ton of getFooOrNull methods. With these methods apps can handle null or missing settings in a special way if they see fit.
closed by #286 |
We're slowly switching to using
reference.conf
for the dual purpose of providing defaults and documenting values. But we have a lot of configuration options where the defaults come from a third party library, for example, a database connection pool provides 20 or so configuration parameters, and it knows best what the defaults should be. So currently, inreference.conf
, we do this:This has the following problems:
This documentation is not self tested. Our code might say:
and that might be the correct way to access it, so the value in
reference.conf
is wrong, and there's no way for us to test that.There's no way to undefine it, so if in development you explicitly set it, but then in your
prod.conf
, which includes the developmentapplication.conf
, you want it to select the libraries default, you can't do this.One possible solution to this is to support or null methods, eg:
Then in
reference.conf
, we can say:The text was updated successfully, but these errors were encountered: