The goal is to make aah logging capabilities into true extendable and futuristic.
Why isn't current logger is capable?
Current logger is extensible and capable no doubt about it. Such as receivers, multiple format, log rotation, Hooks, etc. However I'm envisioning to make it adaptable further.
How does it make a difference?
I'm aiming to make -
log.Logger interface
Log target (removing hooks in-favor of targets)
Multiple targets
Log level config for the target
Log formatter at target level (OOTB targets like console, file, HTTP, etc),
aah user could added/create own log target compliant with target interface
Composable log flags
aah user could add/extend it with own log flag easily
Sematic way to get logger instance at various levels (may be like aah.Log().GetLogger("UserController") - currently just a thought)
Ability to Mask values before logging, configurable way - Sensitive information kept safe
etc.
How does it align with aah's roadmap?
Redefining logger is important for overall framework also upcoming modules like IoC, Data Access Layer, etc.
The goal is to make aah logging capabilities into true extendable and futuristic.
Why isn't current logger is capable?
Current logger is extensible and capable no doubt about it. Such as receivers, multiple format, log rotation, Hooks, etc. However I'm envisioning to make it adaptable further.
How does it make a difference?
I'm aiming to make -
log.Loggerinterfacetarget(removing hooks in-favor of targets)levelconfig for thetargetformatterat target level (OOTB targets like console, file, HTTP, etc),targetinterfaceflagsflageasilyaah.Log().GetLogger("UserController")- currently just a thought)Maskvalues before logging, configurable way - Sensitive information kept safeHow does it align with aah's roadmap?
Redefining logger is important for overall framework also upcoming modules like
IoC,Data Access Layer, etc.