De-singleton ZPageServer implementation #4935
Conversation
|
nice! Thanks! |
Codecov ReportBase: 91.00% // Head: 90.98% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #4935 +/- ##
============================================
- Coverage 91.00% 90.98% -0.03%
+ Complexity 4839 4838 -1
============================================
Files 546 546
Lines 14439 14439
Branches 1395 1395
============================================
- Hits 13140 13137 -3
- Misses 894 900 +6
+ Partials 405 402 -3
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
| .setSpanLimits(getTracezTraceConfigSupplier()) | ||
| .setSampler(getTracezSampler()) | ||
| .build(); | ||
| } |
There was a problem hiding this comment.
I would have this accept a SdkTracerProviderBuilder as an argument to make it more flexible.
Also, can we add test coverage for this method?
| * | ||
| * @return new SdkTracerProvider | ||
| */ | ||
| public SdkTracerProvider buildSdkTracerProvider(SdkTracerProviderBuilder builder) { |
There was a problem hiding this comment.
I would have this return void, but don't feel strongly since its a convenience method and is experimental.
There was a problem hiding this comment.
Cool. Yeah I totally see where you're coming from, but pure side-effect methods also give me the creeps. :)
* remove the static/singleton nature from ZPageServer * add convenience method for creating zpages-based sdktracerprovider * update readme for zpageserver * oh checkstyle. * overload build and add test
This addresses #1414.
I tried it with two instances and it seemed to work fine. I also included some simple manual span creation in the example for people to test with easily.