eclipse / microprofile-telemetry

microprofile telemetry
Apache License 2.0
16 stars 16 forks source link

Support use of arquillian REST protocol #112

Closed Azquelt closed 10 months ago

Azquelt commented 10 months ago

Fixes #72

Azquelt commented 10 months ago

It's worth noting there are other ways to fix this problem.

We could start a test span at the start of each test without the parent context. When we query the InMemorySpanExporter, we could look only for spans with a traceId which matches the test span. However, this may make it harder to tell what has gone wrong if a test fails since the span is not found rather than found with the wrong traceId. It also makes it harder to ensure that the implementation is not accidentally making extra spans with a different traceId. In the OpenLiberty tests we get around this by logging if the InMemorySpanExporter exports a span which is not claimed by any test at app shutdown and then checking the logs, but we can't do that in the TCK.

The problem of having a test REST application pick up the Arquillian REST resource, causing a conflict if the test application has a resource mapped to "/" is very unfortunate. I'd like to see if there's anything we can do in Arquillian to avoid this happening.

We could work around it by implementing getClasses() to avoid triggering autodiscovery, but we'd need to do that consistently in every test application.