config
config copied to clipboard
lightbend
Provide log statement when includes are missing
Today I learned the hard way that HOCON allows for include files to be missing and "silently ignored". I'd like to request that while an exception need not be thrown, some logging (perhaps WARN level) would be a helpful signal to developers who may not be expecting this behavior.
Additionally, once #121 is implemented, the log message could suggest the alternative syntax if the developer does want the missing include to throw an error. Something like "include.conf not found, use required include syntax to make this an error".
The problem is that we don't have a logger... only System.err.println. There would be no way to silence spam on stderr, so to date we've avoided ever printing anything. What we do have is -Dconfig.trace=loads, which should log about this already. Maybe there's some way to look for and use slf4j etc. reflectively, but that seems sort of dangerous too.
Perhaps config could use slf4j, as as far as I can tell it's stable. Another option is java.util.logging..
On Tue, 5 May 2015 13:56 Havoc Pennington [email protected] wrote:
The problem is that we don't have a logger... only System.err.println. There would be no way to silence spam on stderr, so to date we've avoided ever printing anything. What we do have is -Dconfig.trace=loads, which should log about this already. Maybe there's some way to look for and use slf4j etc. reflectively, but that seems sort of dangerous too.
— Reply to this email directly or view it on GitHub https://github.com/typesafehub/config/issues/313#issuecomment-99071585.
The problem is that we have a "no dependencies" policy so far for config. I guess java.util.logging isn't a dependency, but using it may well annoy people... does anyone use that thing?
we could probably do something here, but needs some discussion with akka/play to be sure we aren't going to cause a problem.
One possibility is to do runtime detection for the precense of SLF4J and use that if available, and fall back to java.util.logging if missing.
On Thu, May 7, 2015 at 3:26 PM, Havoc Pennington [email protected] wrote:
The problem is that we have a "no dependencies" policy so far for config. I guess java.util.logging isn't a dependency, but using it may well annoy people... does anyone use that thing?
we could probably do something here, but needs some discussion with akka/play to be sure we aren't going to cause a problem.
— Reply to this email directly or view it on GitHub https://github.com/typesafehub/config/issues/313#issuecomment-99864588.
Cheers, √
@havocp Can you detail more on the no dependencies policy? I knew there is one in place, and I understand the risks involved, but the reason I mentioned SLF4J is because, at least from where I stand, it's proven to be well maintained in terms of backwards/forwards compatibility, much like Joda-Time, and I basically consider it an extension of the standard library.
@viktorklang I like your idea, and I've seen that pattern in (I believe) Jackson to optionally support Joda-Time. If Havoc is happy with that approach I'd be happy to have a go at it, but do you have any good references on how to do it? Or perhaps more how to avoid common pitfalls in implementing it (the runtime detection / utilisation, not the logging part). Thanks.
As a side-note your comment made me think "Yeah that would be great, that can stand on it's own two legs, it could be a stand-alone library... oh, hold on, then it's a dependency.." :D
"No dependencies" is essentially a requirement from the Akka team, though it makes sense - the idea is to avoid locking people to a certain version of some other library, just because the config library uses it.
I guess how you would do this without dependencies would be something like, look up slf4j on the classpath; if present, use reflection to grab/invoke the needed methods. There's already some (optional) logging to stderr in the library, and we could make that also log to slf4j if slf4j is present, or log to only slf4j if slf4j is present. My only hesitation about slf4j-only is that it used to have no easy way to just get debug on stderr; the "just print to stderr" slf4j module always ignores debug level, iirc? but that could maybe be solved by using info always, I don't know.
I just ran into this issue: when overriding the application.conf via -Dconfig.file= and including another config file there it just silently doesn't load the included file. Took me two hours to figure that out.
If we do not want to have slf4j in deps, since Java 9 we have System.getLogger. This thread was before it was released. Think, it's time to add it
