Fail of source is not available

[stanislav-kobylansky]

At this moment there is no way to see what something went wrong on loading configs. E.g. following code, in case when 'appconfig.properties' doesn't exist, will print null without any way sign problem:

@Config.Sources({"classpath:appconfig.properties"})
public interface AppConfig extends Config {
    @Key("app.dataPath")
    String dataPath();
}

public class Main {
    public static void main(String... args) {
        AppConfig cfg = ConfigFactory.create(AppConfig.class);
        System.out.println(cfg.dataPath());
    }
}

I suppose in this situation would be better to throw exception, as there is no other way to identify that something went wrong. Framework should not just swallow such things.

[lviggiano]

This behavior is by design. If you are missing the resource in yuor classpath the framework returns null or the value specified by @DefaultValue. Missing resources in your program is a programming mistake, not an exception. Not gonna change this.

[stanislav-kobylansky]

Not arguing that that is programming mistake, but there is no way for the program to identify that it happened, framework doesn't provide that capability to fail if user want it to happen. There is no way to distinguish just a missing property and the absence of the config, which was explicitly specified by developer.

You decision, of course, but it doesn't sound right.

[loveperl]

I have a suggestion that I think will make everyone happy:

In the scenario that stanislav-kobylansky provided, when OWNER sees that the specified properties file is not on the classpath, OWNER should: (1) State this fact via an SLF4J logging statement at the appropriate level. (2) Continue to behave as it currently does, by NOT throwing any exception.

As a user of the OWNER library myself, I've often wanted to know how OWNER determines the final value for a particular property, after considering OWNER's cascading and default values and other logic. Thorough logging of these determinations (at an appropriate level of course) would be a very useful feature to have, well beyond the aforementioned scenario. Logging would allow the programmer to discover/troubleshoot his or her own programming mistakes.

Another suggestion, building on my logging suggestion, is to create an additional, boolean, argument to the "Config.Sources" annotation to indicate "requiredness". If the argument indicates the properties file is required, but the file is not found, then log this as an error while still otherwise behaving the same.

[lviggiano]

I'll think about it.

I am not keen to add logging to owner (and related dependencies). I could add an event that notifies the user of the files being loaded with eventual exception event on load. In this case the user can attach an event listener that is called when an exception happens (i.e. file not found) while trying to resolve then @Sources, and just print a log info in his own logging system.

But this is not high priority at the moment.

[drapostolos]

+1 for adding logging. I use a merge strategy when reading 4 to 5 different .properties files. It would be nice to see a logging statement saying which .properties files (their paths) where used and in which order (as the user might not always have the source code to check).

[lviggiano]

:+1: message received :)

[lviggiano]

reference to #170

[jonn-smith]

I would also find this feature useful.

One additional possibility is adding a method to the Accessible interface (similar to the list method) to print out the properties (with their pedigrees in a comment above them).

[rnc]

+1 for some form of configurable logging

[mchenryc]

+1 for logging, and a vote for slf4j-api, which has adapters for other logging frameworks (or none).

There is a good response on SO to the question: Is it worth wrapping a logging framework (e.g. as a set of events to be logged by consumers).

Also see slf4j's FAQ on the topic of making slf4j an optional dependency which concludes:

For the above reasons, developers of frameworks should resist the temptation to write their own logging wrapper. Not only is it a waste of time of the developer, it will actually make life more difficult for the users of said frameworks and make logging code paradoxically more vulnerable to change.

Log4j 2 offers similar functionality, separating API and implementation, and also more features, though slf4j-api is 1/7 (40 KB / 285 KB) the size of log4j-api.