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

Slf4jLogConsumer improvements #1986

Merged
merged 4 commits into from
Oct 30, 2019

Conversation

toadzky
Copy link
Contributor

@toadzky toadzky commented Oct 18, 2019

  • Adds support for MDC
  • Uses log levels based on output type

logger.info("{}{}", prefix.isEmpty() ? "" : (prefix + ": "), utf8String);
break;
case STDERR:
logger.error("{}{}", prefix.isEmpty() ? "" : (prefix + ": "), utf8String);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels a tad risky; STDERR isn't solely used for 'error' output in practice, so it might cause confusion to map it to the logger's error level.

I think it's one of those situations where there's no right answer...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i'm not sure there would be confusion. standard out and standard error are different output streams. IMO it's more confusing to have them on the same log level because they are different streams.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, output appearing on standard error can encompass any kind of diagnostic output and is not necessarily an error - the severity is ambiguous. Logger error level really is for errors.

I don't think we should ascribe a meaning that isn't necessarily there, which is why the current implementation is as it is.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's literally the standard error stream. you have ascribed your own meaning to it by classifying something with a different name and purpose as normal output.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's the name, but the specification is for it to carry diagnostic output, and that's what it is used for in real life. I don't think we should by default treat it differently from stdout, which is why they are both currently mapped to the same log level.

How about this: we could have an opt-in parameter to control whether stderr is mapped to error level logs. This way, people can choose what's best for them according to how the specific container behaves.

Copy link
Contributor Author

@toadzky toadzky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated to make the separate log streams an opt-in configuration

return this;
}

public Slf4jLogConsumer separateOutputStreams() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
public Slf4jLogConsumer separateOutputStreams() {
public Slf4jLogConsumer withSeparateOutputStreams() {

@rnorth
Copy link
Member

rnorth commented Oct 30, 2019

Thanks for making the change - I just have one final tweak request and then I think we're good to merge.

@toadzky toadzky force-pushed the slf4j-log-consumer-improvements branch from 473e930 to be5eb82 Compare October 30, 2019 12:46
@rnorth
Copy link
Member

rnorth commented Oct 30, 2019

Thanks @toadzky - will merge

@rnorth rnorth merged commit c5c24a5 into testcontainers:master Oct 30, 2019
@bsideup bsideup added this to the next milestone Nov 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants