The new CONTROL_RESULT_CONFLICT returned by the lease_cmds hook library
indicates that the command was processed ok, but the library was unable to
apply configuration changes because of the conflicting state of the server.
Reportedly, this improves compatibility between gcc 8 and boost 1.75.
Taking the removed comment into account, this seems to come at the
cost of reduced compatibility with SunStudio. Seems like a trade-off
worth making on top of the fact that it simplifies the code.
When multiple loggers are configured, it is possible that a child logger is
processed before the root logger. The order that is in `loggers` configuration
seems to be respected. This could have been a feature in itself, but to keep
it simple and according to the documentation, the root logger was placed in
front of the list on `applyLoggingCfg()`. The root logger that is currently
configured is now always the one that is inherited.
Deleting the root logger is another scenario that could have been problematic.
However, all the specifications are processed through a locally declared
`LoggerManager`. When it goes out of scope it destructs, causing `delete impl_`
which resets `root_spec_`. So when reconfiguration comes, it's like the
previous root logger was never there. We benefit from this default behavior,
and there is no other redundant resetting of root_spec_.
Unlike severity and debug level that have inheritance support embedded
in log4cplus, output_options do not. This commit adds support for this
inheritance by storing a copy of the root logger's specification and
using it on child loggers if they don't have a specification themselves.
Inheritance of severity + debug level is already supported by log4cplus.
This is already tested in:
* LoggerTest.SeverityInheritance
* LoggerTest.EffectiveSeverityInheritance
* LoggerTest.DebugLevelInheritance
To benefit from inheritance, the user first has to be able to omit the
severity. As a result, a missing severity no longer throws an
exception. The exception did not even do a good job of preventing wrong
severity values. Try configuring "severity": "FOO" to see that it does
not get caught on this point.
