-
Notifications
You must be signed in to change notification settings - Fork 363
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
Support user-defined logger instance #365
Comments
Thank you - yes, that sounds like a good improvement. Please feel free to submit a PR |
johnweldon
pushed a commit
that referenced
this issue
Apr 6, 2022
* [#365] - support for configurable logger
cpuschma
pushed a commit
to clementblaise/ldap
that referenced
this issue
Apr 25, 2022
* [go-ldap#365] - support for configurable logger
m-vinc
pushed a commit
to m-vinc/ldap
that referenced
this issue
Jun 15, 2022
* [go-ldap#365] - support for configurable logger
inv2004
pushed a commit
to inv2004/ldap
that referenced
this issue
Jan 17, 2023
* [go-ldap#365] - support for configurable logger
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
First off, thank you for creating the
go-ldap
library and sharing it with the community.Using the optional debug logger was helpful while integrating the library. When transitioning from dev/test to a prod version of an application, the debug logger can be disabled, which is super convenient. If a project that imports the library uses a custom logger instance, the library has a fallback to the default
log.Logger
instance in certain scenarios, which log the messages to stderr and may not be ideal. It would be helpful to inject alog.Logger
instance into the library to handle these cases in a way that is consistent with the rest of the application.If this is functionality that you think that others in the community would benefit from, I can submit a PR.
The text was updated successfully, but these errors were encountered: