Logging and Configuration Systems: Circular Dependency

Question

Assume a typical scenario where the initial settings of an application are loaded at startup from a configuration file. The application also has a logger. The parameters of the logger (e.g. verbosity level, log file path, etc.) are ideally also stored in the configuration file. However, it is also desirable that the configuration loader log information about parameter loading, for example

Attempting to load parameter LogVerbosity. Parameter is absent. Using the default value: 4.

Thus, we see a circular dependency between the two components. The configuration loader needs a ready-to-use logger, and a logger needs configuration parameters to initialize itself. This seems to me to be a problem typical enough to have canonical solutions to it, but I was unable to find anything.

Of course, one can roll some ad-hoc solutions but I'm interested in the best industry practices.

Hope the question makes sense.

Answer 1

I assume that you want to log parameters in order to be able to investigate them later on, for example in the case of a bug. What is obvious, it's possible only if they'll be persisted in a file or another storage. It implies that a logger must be properly configured in order to do so. So the basic question is:

Can we assume that a logger will be able to log at least startup parameters?

Yes

This case is trivial. I'd simply:

1. Read configuration parameters of a logger.
2. Initialize a logger.
3. Log parameters of a logger.
4. Read other parameters.
5. Log other parameters.

No

This case is more complex. I think that a good solution is to use a default, hard-coded set of parameters for a logger. It will guarantee that it'll be possible to safely log startup parameters:

1. Initialize a logger with default (hard-coded) parameters.
2. Read configuration parameters.
3. Log parameters.
4. Initialize a logger based on the parameters from the configuration file.
5. Try to log parameters once again.

If a configuration of a logger is correct you'll be able to find all parameters in a standard log location. If a configuration is wrong, you still will be able to find them but in the default (hard-coded) location.

Alternatively, instead of using a logger in the step 1, you can simply write startup parameters to a file (in a working directory of an application) using standard mechanisms like fstream...

Additional comments

Some logging libraries like nlog can be configured (throwExceptions = true) to raise errors in the case of a wrong configuration. Unhandled exceptions should be then logged by an operating system.

If you use a logging library of this kind you can turn this option on and use a solution 1 above. If application started then you'll find startup parameters in a log. If it didn't started, you should examine a system log.