- Notifications
You must be signed in to change notification settings - Fork 313
Adding Support for TRACE_PROPAGATION_BEHAVIOR_EXTRACT
#8535
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
Changes from all commits
518aae0
8ff205b
30e7c6c
3527a7f
7ebfa65
9ef2479
14891f7
623e7ba
465421c
f4538a7
2c51a78
d0bd3f5
4975d23
dc499ea
269d68a
7a0fcd5
9d10393
534b1ff
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,24 @@ | ||
package datadog.trace.api; | ||
| ||
import java.util.Locale; | ||
| ||
/** Trace propagation styles for injecting and extracting trace propagation headers. */ | ||
public enum TracePropagationBehaviorExtract { | ||
CONTINUE, | ||
RESTART, | ||
IGNORE; | ||
| ||
private String displayName; | ||
| ||
TracePropagationBehaviorExtract() { | ||
this.displayName = name().toLowerCase(Locale.ROOT); | ||
} | ||
| ||
@Override | ||
public String toString() { | ||
if (displayName == null) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This can just be simplified like this:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I even proposed an early initialization in constructor :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Does implementing the initialization in the constructor take care of all cases where | ||
displayName = name().toLowerCase(Locale.ROOT); | ||
} | ||
return displayName; | ||
} | ||
} |
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.
For the record, enum can have constructor too.
So you should be able to set the
displayName
final and compute it in constructor.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.
TBH I'm not sure what the benefit of having a constructor here... where would it actually be used? I added one constructor in the new commit, but not sure if it is what you were imagining.
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.
The main difference between the lazy and the constructor will be the initialization time.
For the lazy, it will be done when accessing the string representation (so when parsing config).
For the constructor one, it will be done when loading the type.
For lazy initialization, you might need to care about async access and prevent double initialization on concurrent access.
All of those is advice for general programming. In this case, it does not matter much as
Config
will appear near startup, and the initialized resources are not significant.What I had in mind about the constructor was:
The same initialization than yours on
toString()
but moved already to simplify the logic.Its mostly for the sake of Java discussion, there is no real impact for you PR 😉