-
Notifications
You must be signed in to change notification settings - Fork 576
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
Contextual logging #1404
Contextual logging #1404
Conversation
Not putting this up for a vote yet (will wait a few days), because some people on IRC have been working on alternative proposals. |
a59bf65
to
7392c2f
Compare
I've also updated Mojolicious default log messages to include the request id when possible. Performance cost seems pretty minimal, less than 2% difference for |
Since it now looks like nobody else is working on an alternative proposal, i'll just call for a vote @mojolicious/core. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I really like that the change is so small (disregarding the change from $self->log
to $self->helpers->log
various places). Also went through some implementations we have that do things with the logging (custom formatters etc) and this change does not present itself as any kind of inconvenience.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we might want to revisit structured logging at a major version number, but I'm very happy to have this! +1
@jberger But if we are already planning to revisit structured logging, shouldn't the |
For now, I think assuming a string in the context is fine. The way I see it, later any scalar could be used, including a data structure, and we'd have some additional formatter that would handle structured data when given. That's just my thought though |
That is true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My comments should not be considered blockers for this PR, but I don't want to approve it until I know the reasoning for the design.
😐
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Slight typo. Otherwise lgtm and 👍.
…cious::Plugin::DefaultHelpers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Looks completely backwards compatible and very useful!
EDIT: Rules are made for followin' (in this case)
Just FYI, these changes mean that modules like MojoX::Log::Log4perl will need to be updated. I'm not expecting the Mojolicious team to fix it -- just thought you might like to know. |
This is one possible solution for #1400. The main goals were performance and simplicity. And there would be no backwards compatibility breakage.