-
Notifications
You must be signed in to change notification settings - Fork 900
Add some helpful logging attribute methods #7089
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
Add some helpful logging attribute methods #7089
Conversation
The code looks good to me. Is there anything we should do to address the build failing? |
api/all/src/main/java/io/opentelemetry/api/logs/LogRecordBuilder.java
Outdated
Show resolved
Hide resolved
api/all/src/main/java/io/opentelemetry/api/logs/LogRecordBuilder.java
Outdated
Show resolved
Hide resolved
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7089 +/- ##
============================================
- Coverage 89.86% 89.85% -0.01%
- Complexity 6613 6618 +5
============================================
Files 740 740
Lines 19991 19996 +5
Branches 1966 1966
============================================
+ Hits 17964 17967 +3
- Misses 1437 1443 +6
+ Partials 590 586 -4 ☔ View full report in Codecov by Sentry. |
api/all/src/main/java/io/opentelemetry/api/logs/LogRecordBuilder.java
Outdated
Show resolved
Hide resolved
api/all/src/main/java/io/opentelemetry/api/logs/LogRecordBuilder.java
Outdated
Show resolved
Hide resolved
api/all/src/main/java/io/opentelemetry/api/logs/LogRecordBuilder.java
Outdated
Show resolved
Hide resolved
api/all/src/main/java/io/opentelemetry/api/logs/LogRecordBuilder.java
Outdated
Show resolved
Hide resolved
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 suspect you intentionally include boxed types instead of primitives to allow for null, but I think if we want to settle accepting nullable attributes, we should do it holistically: #4336
Yeah exactly, because I think its safe to pass null and it effectively becomes a no-op. If we do make these primitives, it forces the call site (user code) to have to deal with the nulls in advance...which is good for us because its simpler and takes null out of the equation...but I think it weakens the usability and convenience, which is the whole point. I don't feel super strongly about it anyway though. |
This line in the spec is a bit ambiguous
I can see it meaning that we shouldn't accommodate users submitting null values or perhaps we can take null values, but that the exported values may change and it isn't well documented |
I think we should stay consistent with the |
…er.java Co-authored-by: jack-berg <[email protected]>
…er.java Co-authored-by: jack-berg <[email protected]>
…er.java Co-authored-by: jack-berg <[email protected]>
…er.java Co-authored-by: jack-berg <[email protected]>
It is tedious and hurts readability to have the various attribute key methods sprinkled in user code. This allows users to simply pass the string containing the key name, which is what users want 99.92% of the time.