Adrian Cole

#511 will fix most of this except the actual doc change. The zipkin libs are still pulled in by otel and I added notes about what to do when https://github.com/open-telemetry/opentelemetry-java/pull/6129...

specifically otel is locking into a version of zipkin-reporter-brave which still has a dep on zipkin types. It is easy to fix as I've raised the PR needed by OTEL...

finally I did a [brain dump](https://groups.google.com/g/zipkin-dev/c/x9xiqbVxrNk) here for those who care to parse it. TL;DR; zipkin server needs to be able to upgrade to a different floor version of java...

if it helps progress this, I would suggest peeling off the health endpoint as something easier to land maybe? Use in docker and k8s fills up trace repositories with traces...

A workaround for docker is to configure the HEALTHCHECK to add the header 'b3: 0' (if using brave, as even when outbound propagation is set to b3 multi, inbound leniently...

note @nidhi-nair seemed to need to look up a root context to implement this, though I don't know if it was project-specific https://github.com/appsmithorg/appsmith/pull/24758

@jonatan-ivanov thanks I was able to get something similar working https://github.com/openzipkin/brave-example/pull/120

one thing that became apparent in this exercise is that this is the perfect thing to normalize in a property at least until there's a generic HTTP path accessor. Depending...

since phase 4 is "finished", do you have a sense of which runtimes have been able to implement this considering the disrepair of the spec text, leading to this issue?...

zipkin tests run against our docker image which is MySQL 10.11.7