Adopt swift-log

[ianpartridge]

https://github.com/apple/swift-log/tree/swift-log-0.0 supports Swift 4.1+

[djones6]

A simple implementation that allows a swift-log Logger to be attached to LoggerAPI: https://github.com/djones6/LoggerAPI/tree/swift-log

Sample project using the above: https://github.com/djones6/LoggingTest

Some considerations for use of swift-log with LoggerAPI and/or Kitura:

• Do we want LoggerAPI to log to a default swift-log Logger by default? Or should the user configure this explicitly? I'm leaning toward requiring explicit opt-in because:
  • by default, an otherwise unconfigured Logger will log to stdout, which may be undesirable
  • the logging level is defined on the Logger, rather than the backend (LogHandler), which is the opposite from LoggerAPI (where the logging level is configured on our 'backend' eg. HeliumLogger).
• How do we want to map the LoggerAPI logging levels (error, warning, info, verbose, debug, exit, entry) to the swift-log levels (critical, error, warning, notice, info, debug, trace), and do we want this to be hard-coded or user-configurable?
  • my example hard-codes the following (LoggerAPI -> swift-log):
    • error -> error
    • warning -> warning
    • info -> notice
    • verbose -> info
    • debug -> debug
    • entry / exit -> trace
    • (nothing sent to 'critical')

[djones6]

We may want to provide an API on Kitura itself to set up swift-log, eg: Kitura.logTo(logger: Logging.Logger) - doing this would eliminate the requirement to import / interact with LoggerAPI at all. I'll prototype what this would look like.

[djones6]

Example updated to use Kitura.logTo(logger: Logging.Logger) API which avoids users from needing to interact with LoggerAPI directly:
https://github.com/djones6/Kitura/tree/swift-log
(needs my corresponding fork of LoggerAPI)

Sample project updated using this: djones6/LoggingTest@40fdb1d

[ianpartridge]

@weissi ^^^ any thoughts?

[weissi]

@djones6 / @ianpartridge I'm not sure I understand the question fully. Is the question on where/how to configure the Logging.Logger that LoggerAPI should use?

[ianpartridge]

Sorry, no particular question, just thought you might be interested to see @djones6's current direction on this, and might have comments!

[weissi]

Thank you, that sounds great! I'll also have a look at the code now.

[weissi]

@djones6 Thanks, that all looks really good. I left some comments, mostly that LoggerAPI isn't (and never was) thread-safe and I think there are some extra branches (on the log level) that we don't need.

[djones6]

@weissi Thank you for your comments! I think it makes sense to address thread safety for both logging types. I'll work that up.