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

Replace Logger.{Level,SetLevel} with DynamicLevel #180

Merged
merged 14 commits into from
Nov 21, 2016
Merged

Conversation

jcorbin
Copy link
Contributor

@jcorbin jcorbin commented Nov 14, 2016

Depends on #172, supercedes #173.

After this PR, the only part of #166 left is the CheckedMessage composition work.

@jcorbin jcorbin changed the title WIP: Replace Logger.{Level,SetLevel} with DynamicLevel Replace Logger.{Level,SetLevel} with DynamicLevel Nov 15, 2016
@jcorbin
Copy link
Contributor Author

jcorbin commented Nov 15, 2016

Rebased, ready for review

This was referenced Nov 15, 2016
Copy link
Contributor

@akshayjshah akshayjshah left a comment

Choose a reason for hiding this comment

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

Looks great. Small nits, only one substantive change request.

@@ -35,18 +35,19 @@ type errorResponse struct {
}

type levelHandler struct {
logger Logger
lvl AtomicLevel
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not just add ServeHTTP to the AtomicLevel type? It doesn't add any overhead if it's not used, and it removes one type and wrapper from this now-crowded package.

@@ -105,3 +121,41 @@ func (l *Level) UnmarshalText(text []byte) error {
}
return nil
}

// Enabled return true if the given level is at or above this level.
Copy link
Contributor

Choose a reason for hiding this comment

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

return -> returns

//
// The value's SetLevel() method may be called later to change the enabled
// logging level of all loggers that were passed the value (either explicitly,
// or by creating sub-loggers with Logger.With).
Copy link
Contributor

Choose a reason for hiding this comment

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

nice - this is a much clearer explanation than the parent/child terminology I was using.

@@ -37,37 +33,25 @@ type Meta struct {
Hooks []Hook
Output WriteSyncer
ErrorOutput WriteSyncer

lvl *atomic.Int32
LevelEnabler
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we keep embeds at the top, separated from the other fields with a blank line?

@akshayjshah
Copy link
Contributor

Great - appreciate the quick turnaround after a delayed review. Feel free to merge after resolving the conflict.

@jcorbin jcorbin merged commit dd14720 into master Nov 21, 2016
@jcorbin jcorbin deleted the drop_logger_level branch November 21, 2016 21:28
@anuptalwalkar
Copy link

A quick question on this PR. You seem to have removed the Level access on Logger object. How will a user know what log level is set on the created/passed zap.Logger object?

@jcorbin
Copy link
Contributor Author

jcorbin commented Nov 22, 2016

@anuptalwalkar the idea now is that there isn't necessary a "the level of a logger object" concept; I'd respond to your question of "how?" with a clarifying "why?":

  • if what you're trying to do is do your own filtering style logic, then you should be just calling Logger.Check
  • otherwise, you may want to be using zap zap.DynamicLevel, which you can ask "what's the effective logging level"?

If those don't meet your needs, can you describe your use case a little more? (maybe in a new issue?)

@anuptalwalkar
Copy link

I see. my concerns were around setting up the Logger correctly. So now I can add zap.DynamicLevel as an option, but I can't add zap.DynamicLevel().SetLevel(zap.WarnLevel) as an option.

@anuptalwalkar
Copy link

Nevermind actually. I understand now. I have updated my changes as well uber-go/fx#81

phungs pushed a commit that referenced this pull request Dec 2, 2016
* make Levels be "just" Options; simplify/extensify meta enabled layer
* drop SetLevel/Level Logger API
* add AtomicLevel option for changeable levels
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants