chore: replaced with dapr-kit logger

[sadath-12]

Description

Currently we use log package for logging whereas we have our own logger available at github.com/dapr/kit/logger which we should make use it

Issue reference

Please reference the issue this PR will close: #[issue number]

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• [] Extended the documentation

[codecov]

Codecov Report

Attention: 2 lines in your changes are missing coverage. Please review.

Comparison is base (c8f3533) 70.26% compared to head (8d5806a) 70.08%.

❗ Current head 8d5806a differs from pull request most recent head a2d551d. Consider uploading reports for the commit a2d551d to get more accurate results

Files	Patch %	Lines
actor/manager/container.go	0.00%	1 Missing ⚠️
client/client.go	80.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #491      +/-   ##
==========================================
- Coverage   70.26%   70.08%   -0.19%     
==========================================
  Files          35       35              
  Lines        2859     2841      -18     
==========================================
- Hits         2009     1991      -18     
  Misses        738      738              
  Partials      112      112              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[mikeee]

I would like to see the logger name kept, we shouldn't have unnecessary package name collisions especially with the standard library.

The service grpc and http documentation should use the standard library / be open to the user.

[sadath-12]

I would like to see the logger name kept, we shouldn't have unnecessary package name collisions especially with the standard library.

The service grpc and http documentation should use the standard library / be open to the user.

you mean to change the name of log to something elsevar log = logger.NewLogger("dapr.actor.manager")

[mikeee]

I would like to see the logger name kept, we shouldn't have unnecessary package name collisions especially with the standard library.
The service grpc and http documentation should use the standard library / be open to the user.

you mean to change the name of log to something elsevar log = logger.NewLogger("dapr.actor.manager")

Yep, I just think it looks cleaner than using a naming convention that clashes with the standard library where it doesn't interface cleanly.

[sadath-12]

@mikeee can we think in this way .. because of same name I was able to quickly migrate to new liberary . so maybe that's a plus point over using different names . just thinkering for this let me know if you agree or else ill change

[mikeee]

This is a breaking change whichever way it's looked at. Sure you may have some functions that cross-over but I believe there should be no shadowing of the log package (or anything else in the standard library) unless it retains the same interfaces.

[sadath-12]

ok so shall we do like for example logClient in the client package

[mikeee]

I'm not entirely sure about using kit/logger in a user written application would be preferable.
@qustavo what are your thoughts about this change?

The recent change made by @qustavo allows for a user-specified logger as part of the client created, perhaps this addresses the need to migrate entirely to kit/logger and not change the expected output/functionality of the current logging implementation

[qustavo]

I'm not entirely sure about using kit/logger in a user written application would be preferable. @qustavo what are your thoughts about this change?

From what I can see, the logging requirements for the sdk are minimal. We log.Print[f,ln] and log.Fatal[f] and the current logging implementation is sufficient. That being said, we could support a custom logger injection if SetLogger accepted an interface rather than a concrete implementation, so that you can bring your own logger, although that might be overkill.

In general I'd wait until the need for a more elaborated logging strategy is needed.

@sadath-12 is there a use case for using kit/logger that I'm overlooking?

go-sdk/client/client.go

Line 68 in 7e5ee73

func SetLogger(l *log.Logger) {