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.