would an “override” modifier make sense? about config

[viktorklang]

Would be nice with a "help" mode that checks the key inside all the fallbacks and suggests: "Did you mean xxx.yyy.key ?"?

[viktorklang]

And use something like Levenshtein distance to do fuzzy matching to detect misspellings: http://commons.apache.org/lang/api-2.4/org/apache/commons/lang/StringUtils.html#getLevenshteinDistance(java.lang.String, java.lang.String)

[havocp]

It's a bit awkward that we don't really have a way to print a warning (without putting a logger dependency in the config lib). We can either throw an exception or be silent.

One option could be to have a method which returns a list of warnings for a subtree (such as the akka subtree), similar to the current checkValid but with warnings not exceptions... then Akka for example could call this method (on the akka subtree only) and log the result.

It might basically complain about any setting which doesn't either 1) override another setting from reference.conf or 2) get used from a ${} expression.

Another idea would be something like -Dconfig.verbose=1 which would print warnings to stderr but I don't like it much since people won't know to turn it on.

[viktorklang]

You could pass in a "logger" when constructing the Config through the ConfigFactory, and default to a "logger" that does nothing.

[rkuhn]

But it would still need special syntax: we do not want warnings all over the place because people define custom dispatchers. The check can only work if it is limited to settings which the end user marked as “do check”. The docs could make it clear that this should be the normal way to declare things, though.

[havocp]

I wonder if the special syntax should be opt-out instead of opt-in? i.e. the special syntax would mean "it's OK that this isn't used" or even "this should NOT override anything"

If we are willing to have each framework do a little work we might be able to handle things like custom dispatchers, too (I don't know exactly how, would have to work on it).

Or another option is that the "special syntax" is "use another prefix," that is, don't put your custom setting underneath akka {} ?

Just half-baked ideas from me here, it deserves some time working out details.

[patriknw]

On Sep 21, 2012, at 0:15, Havoc Pennington [email protected] wrote:

I wonder if the special syntax should be opt-out instead of opt-in? i.e. the special syntax would mean "it's OK that this isn't used" or even "this should NOT override anything"

If we are willing to have each framework do a little work we might be able to handle things like custom dispatchers, too (I don't know exactly how, would have to work on it).

Or another option is that the "special syntax" is "use another prefix," that is, don't put your custom setting underneath akka {} ?

That might be a problem for akka. We are strict in defining default values, but for example the akka.actor.deployment. is more advanced than normal defaults.

Just half-baked ideas from me here, it deserves some time working out details.

—
Reply to this email directly or view it on GitHub.

[rkuhn]

I wonder if the special syntax should be opt-out instead of opt-in? i.e. the special syntax would mean "it's OK that this isn't used" or even "this should NOT override anything"

No, I think it is imperative that we keep the default “open”, i.e. by default you can just put anything you want anywhere in the config tree and nobody will complain (unless a consumer does not like the value’s format). As Patrik pointed out we need this flexibility, and not only for our own data but if people write their own Dispatcher implementations they’ll get the config section (complete) where they make use of it and can this way pass their own non-akka config in. Schema-less is fine!

[patriknw]

On Thu, Sep 20, 2012 at 11:05 PM, Havoc Pennington <[email protected]

wrote:

It's a bit awkward that we don't really have a way to print a warning
(without putting a logger dependency in the config lib). We can either
throw an exception or be silent.

One option could be to have a method which returns a list of warnings for
a subtree (such as the akka subtree), similar to the current checkValid but
with warnings not exceptions... then Akka for example could call this
method (on the akka subtree only) and log the result.

I kind of like this suggestion instead of logging. We already use
checkValid and this would follow the same path.

It might basically complain about any setting which doesn't either 1)
override another setting from reference.conf or 2) get used from a ${}
expression.

Another idea would be something like -Dconfig.verbose=1 which would print
warnings to stderr but I don't like it much since people won't know to turn
it on.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/39#issuecomment-8745591.

Patrik Nordwall
Typesafe http://typesafe.com/ - The software stack for applications that
scale
Twitter: @patriknw

[havocp]

So to step back and define the problem, I guess the goal is:

• try to eliminate the FAQ that people configure the wrong key and it does nothing

(this is also an SBT FAQ, incidentally...)

Some properties of a really nice solution I think would be:

• is enabled by default / in the documented way to do it (otherwise it won't fix the FAQ right?)
• works with all the syntax variants (JSON, HOCON, .properties, hypothetical future ones)
• no false alarms, or at least an easy way to "silence" any false alarms
• doesn't interfere with ability to have settings that are unknown to Akka (or unknown to whatever other code is also using the config file)

Some things I think we could compromise if they enable a nice solution:

• require some extra code from library/framework developers
• some "namespaces" are treated differently from others (this is already done to a small extent, with checkValid used to check "your own" namespace only)
• warnings are somewhat heuristic (for example, it's OK if some broken situations don't trigger warnings, as long as we still reduce FAQs by warning about common problems)
• ??? it's always helpful to make more "what could we budge" options like this when looking for solutions

So, how might we get the really nice solution... surely there's some answer. A little late at night for me right now though so I'll see if sleeping on it helps ;-)