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

Make log statements part of the public API #4159

Open
timbussmann opened this issue Sep 26, 2016 · 4 comments
Open

Make log statements part of the public API #4159

timbussmann opened this issue Sep 26, 2016 · 4 comments
Milestone

Comments

@timbussmann
Copy link
Contributor

We have users which rely with their logging configuration on our internal implementations. E.g. if you want to log something which is by default logged in a log level you don't want to have across the whole application. Concrete scenario as discussed here: #2074: Immediate retries are logged with level INFO, delayed retries with WARN. If you want to log immediate retries, it doesn't make sense to change the log level for the full application to info, so you have to configure that explicit logger (e.g. NServiceBus.Unicast.Transport.TransportReceive ) to INFO instead.

There is absolutely no guarantee on the logging between versions. With v6, it will change the logger name from NServiceBus.Unicast.Transport.TransportReceive to RecoverabilityExecutor. As this is no part of our official public API, there is no upgrade guide and no way to ensure the stability of those log statements.

Let's make the log statements above DEBUG level part of the public API. This means

  • We need acceptance tests to verify the logger name, log level and (part of?) the log message.
  • We need to properly handle upgrade paths for users using these log entries (e.g. "deprecating" old/moved loggers)
  • Document changes to the logs.

This would add value for operations to ensure logs and log handling is consistent across versions. Also it enforces us to give more attention to log statements above DEBUG.

@danielmarbach
Copy link
Contributor

Since we discussed it already together I can only add a self-biased: I like it

@andreasohlund
Copy link
Member

Would there be value in starting to align the loggers around our folder(capability) structure.

Eg. things around recoverability would be using the NServiceBus.Recoverability logger?

Would that be to coarse grained?

@danielmarbach
Copy link
Contributor

I think component based logging is much more valuable than class based logging.

@timbussmann
Copy link
Contributor Author

I think component based logging is much more valuable than class based logging.

fully agree. This would decouple logging from internal implementations and makes the logs much more readable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants