-
Notifications
You must be signed in to change notification settings - Fork 345
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
[feat] added a slog wrapper of the logger interface #1234
Conversation
Appologies for tagging you @crossoverJie , @RobertIndie , @nodece , but I noticed that the v0.13.0 milestone has a deadline in 2 days. |
@ivan-penchev In this PR, the Go version is upgraded to a minimum of 1.20, but the slog package is officially used in 1.21. This change requires upgrading the Go version to 1.21+. |
Upgrading the Go version looks to be a clear and well defined step. I mean Go is considered feature-complete and lacks an LTS version, it's generally expected to maintain compatibility with the last two minor versions, as seen on their download page (https://go.dev/dl/). But I've read some issues here indicating a more conservative update strategy for this SDK. Is that the case? Do I have to wait til Go 1.23 before we can merge this? Edit: @crossoverJie I decided to give the upgrade a chance, after reading go's release policy. I hope I haven't done anything bad. |
69aade1
to
205e414
Compare
I have no objections to upgrading to 1.21. We've already skipped 1.18 to 1.19, so skipping 1.20 as well doesn't seem problematic. |
Co-authored-by: Zixuan Liu <[email protected]>
Co-authored-by: Zixuan Liu <[email protected]>
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.
LGTM
@ivan-penchev I noticed this PR doesn't add a test, could you add a test for the producer and consumer with this logger? |
@nodece I appreciate the need for a test to accompany this update. I'm willing to try writing one, but I could use some assistance, given that the current test suite doesn't cover the logger.
For 2 you could see - in my PR description, I did an integration test where I started a producer with logrus, and producer with slog - and then I compared the output of both loggers, in terms of length and keys (since I was doing json). But this seems too complicated and not needed for what I was trying to test. So I would be provocative and ask, do we even need a test? |
You can write a test in the
All right.
/// Licensed to the Apache Software Foundation (ASF) under one
// or more contributor license agreements. See the NOTICE file
// distributed with this work for additional information
// regarding copyright ownership. The ASF licenses this file
// to you under the Apache License, Version 2.0 (the
// "License"); you may not use this file except in compliance
// with the License. You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing,
// software distributed under the License is distributed on an
// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
// KIND, either express or implied. See the License for the
// specific language governing permissions and limitations
// under the License.
//go:build go1.21
package pulsar
import "testing"
func TestClientWithSlog(t *testing.T) {
}
You only need to verify the client with slog works fine. You can also verify the log output: // Licensed to the Apache Software Foundation (ASF) under one
// or more contributor license agreements. See the NOTICE file
// distributed with this work for additional information
// regarding copyright ownership. The ASF licenses this file
// to you under the Apache License, Version 2.0 (the
// "License"); you may not use this file except in compliance
// with the License. You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing,
// software distributed under the License is distributed on an
// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
// KIND, either express or implied. See the License for the
// specific language governing permissions and limitations
// under the License.
//go:build go1.21
package log
import (
"context"
"log/slog"
"testing"
"github.com/stretchr/testify/assert"
)
type defaultHandle struct {
records []slog.Record
}
func (d *defaultHandle) Enabled(ctx context.Context, level slog.Level) bool {
return true
}
func (d *defaultHandle) Handle(ctx context.Context, record slog.Record) error {
d.records = append(d.records, record)
return nil
}
func (d *defaultHandle) WithAttrs(attrs []slog.Attr) slog.Handler {
panic("implement me")
}
func (d *defaultHandle) WithGroup(name string) slog.Handler {
panic("implement me")
}
var _ slog.Handler = &defaultHandle{}
func TestSlog(t *testing.T) {
handler := &defaultHandle{}
logger := slog.New(handler)
logger.Info("1")
assert.Equal(t, handler.records[0].Level, slog.LevelInfo)
assert.Equal(t, handler.records[0].Message, "1")
} Thanks for your time! |
If everyone is OK with the suggested changes, would someone be able to merge this in? |
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.
Thanks for your contribution! LGTM.
Yes. We can include this in v0.13.0. |
Hi 👋, first time contributor here
Motivation
My team uses
log/slog
package from the standard library to control the level and output type of our logs in our services.In order for us to not have to import logrus as a direct dependency for part of our testing suit, it would be nice if we can use
slog
package instead, and wrap that in the provided bypulsar/log
interfaces.This ties in a bit with issue #1078 because it opens the door for users who are already working with log/slog in their projects. Plus, it's a gives more time for the Pulsar team to evaluate incorporating slog into the SDK.
Explain here the context, and why you're making that change. What is the problem you're trying to solve.
Modifications
One additional file
/pulsar/log/wrapper_slog.go
is added.One additional function in the
pulsar/log
package,NewLoggerWithSlog
, is exposed.Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:
If
yes
was chosen, please highlight the changesDocumentation
Notes
Please direct me if I'm missing something 😄.
I attempted to include a meaningful test to enhance the quality of this pull request. Regrettably, I was unsuccessful, as none of the scenarios I considered seemed appropriate.
Throughout the development process, I utilized testcontainers, which I recognize cannot be added because it would introduce an unnecessary dependency. As well as it creates a circular dependacy between
pulsar
andpulsar/log
.However in order to verify the changes I am submitting I created a file named
log_test.go
in the root directory of the repository. Within this file, I initiated an Apache Pulsar testcontainer, then set up both a logrus logger and an slog logger. These were utilized to establish a client and a producer. Subsequently, I compared the length of the output from both loggers to ensure the keys corresponded.Below is the test for those interested in confirming that this change functions correctly:
Integration test code, must run go mod tidy before you run