Open bsutton opened 3 years ago
Anyone will to have a crack of building/selecting a logging framework that we use/export as part of the dcli package. Or should we just leave this to the user to choose?
slf4j loggers look problematic as I suspect that java uses reflection.
@jorgecoca @felangel can we do a joined effort and create a new timber
/lumberdash
without the maintenance trouble?
@jorgecoca @felangel can we do a joined effort and create a new
timber
/lumberdash
without the maintenance trouble?
I think we need to align on what value this new package would bring over the existing packages.
@felangel I think that is a valid concern.
Ideally we should be able to adapt to whatever logger the user chooses.
There would be a significant effort in building and maintaining our own.
One idea is to build a separate set of adaptor packages. One for each of the popular loggers. The user then adds the appropriate adaptor package to dcli.
We really need to look at selecting a logging framework which we use and recommend.
It would be nice if there was something similar to java slf4j-api.logger which is able to work with an array of logging provider. This allows the user to choose their logger and dcli would then log via that provider. This may not be possible without using mirrors which I would prefer to avoid.
Alternativley we could extend the existing setVerbose logging.