* Detect GC leaks of scopes in StrictContextStorage.
* More
* Finish
* Force GC more aggressively
* Cleanup
* Vendor code directly
* Copy test too
* Try waiting more
* ep
* oops
* Remove from build.gradle
* Drift
* Log on multiple
* Cleaner ourselves.
* EP
* Move into if
* Revert accidental
* Hide implementation of MultiSpanExporter behind interface.
* spanprocessor too
* composite
* composite
* Optimize composites based on number of items.
* Spotless
* IntelliJ + spotless race condition
* Fix test
* Report BatchSpanProcessor current queue size
Signed-off-by: Ruben Vargas <ruben.vp8510@gmail.com>
* class name and span processor label to static fields
Signed-off-by: Ruben Vargas <ruben.vp8510@gmail.com>
* Make the OpenTelemetrySdk a subclass of DefaultOpenTelemetry
* Remove SPI from the explicit OpenTelemetrySdk builder usage.
Add a (super ugly) test to make sure that the clock and resource are getting set.
* Update sdk/all/src/test/java/io/opentelemetry/sdk/OpenTelemetrySdkTest.java
Co-authored-by: Anuraag Agrawal <anuraaga@gmail.com>
* Update sdk/all/src/test/java/io/opentelemetry/sdk/OpenTelemetrySdkTest.java
Co-authored-by: Anuraag Agrawal <anuraaga@gmail.com>
* address code review comments; add tests
* Require the MeterProvider to be a MeterSdkProvider
Co-authored-by: Anuraag Agrawal <anuraaga@gmail.com>
CHANGELOG: the SDK will no longer throw an exception with a null instrumentation name on tracers or meters, but this is still not recommended usage.
* Provide a default Tracer and Meter for invalid instrumentation names
According to the spec, https://github.com/open-telemetry/opentelemetry-specification/blob/v0.6.0/specification/trace/api.md#tracerprovider-operations both a null and empty instrumentation name are invalid and a default implementation should be provided.
However, the spec is vague on what default means. See https://github.com/open-telemetry/opentelemetry-specification/issues/586#issuecomment-669856711
This change interprets "default" as meaning, "it should still work, but it's not ideal". Accordingly, a real Tracer or Meter implementation from the SDK is used. It meets the requirements of exporters and such by using a valid instrumentation name. It meets the requirements of application developers by producing valid tracing data. It also warns library and application developers by logging at the WARN level that an invalid value has been given.
The rational for this interpretation is that things should always work for the application developer. If an app developer doesn't provide a name, they should be chided, but they are instrumenting their own app, and likely don't care about the lack of name. If an app developer incorporates a library that doesn't specify the instrumentation name, the instrumentation should still be made available to application devs, but they should be able to turn if off (hence a valid name) and be made aware of something not being right (hence the logging) so they can report it to the library maintainers.
Fies #1879
* Mark instrumentation version nullable in MeterProvider and TracerProvider
The spec dictates this to be optional, and the implementations treat it as nullable already.
* Remove ComponentRegistry#get(String) overload
This overload is not no longer used by our code.
* fixup! Mark instrumentation version nullable in MeterProvider and TracerProvider
* fixup! Provide a default Tracer and Meter for invalid instrumentation names
* fixup! Provide a default Tracer and Meter for invalid instrumentation names
* fixup! Remove ComponentRegistry#get(String) overload
This reverts commit db56814c
* Revert "Mark instrumentation version nullable in MeterProvider and TracerProvider"
This reverts commit 7e92b396
CHANGELOG: Deprecated the `getCanonicalCode` method on `SpanBuilder` ; replaced with `getStatusCode`
* Some cleanup in span land.
* Clean up the SpanBuilder javadoc to match the current APIs
* Scrub mentions of canonical status code
* Deprecate the getCanonicalCode method on SpanBuilder and replace with getStatusCode
* rename an internal method to make more sense
* Update api/src/main/java/io/opentelemetry/api/trace/SpanBuilder.java
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
* Update api/src/main/java/io/opentelemetry/api/trace/SpanBuilder.java
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
* Update api/src/main/java/io/opentelemetry/api/trace/SpanBuilder.java
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
* add tests for the deprecated method
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
* Add assertj helpers for asserting traces and expose from the junit5 helper.
* Style and stability of map
* Revert rename, any order comes in future.
* Add coverage for protected method implementations.
* Test hasTraceId
* Check hasTraceId failure too.
* Make the BatchRecorderSdk actually batch the recordings
Rather than just forwarding them immediately.
* rework the batch recorder to use a queue of recordings
* remove an allocation per recording by introducing some typed classes
* Replace all assertions with AssetJ's assertThat
Remove uses of JUnit 4 and JUnit 5 assert* where a functional equivalent exists in AssertJ. JUnit 5's assertThrows remains.
Fixes#1994
* fixup! Replace all assertions with AssetJ's assertThat
John Watson
Anuraag Agrawal
Prashant Srivastava
Armin Ruech
Mateusz Rzeszutek
Vladimir Šor
Christian Neumüller
Ruben Vargas Palma
Marius Volkhart
dengliming
Carlos Alberto Cortez
Bogdan Drutu