Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redefine aah logging capabilities #232

jeevatkm opened this issue Dec 17, 2018 · 0 comments

Redefine aah logging capabilities #232

jeevatkm opened this issue Dec 17, 2018 · 0 comments


Copy link

jeevatkm commented Dec 17, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
aah Roadmap

No branches or pull requests

1 participant