opentracing can not be disabled with runtime config.

Describe the bug Setting the property -Dquarkus.jaeger.enabled=false when executing the jar produced by running [my-package]-runner.jar, or via native-image, does not disable jaeger.

Expected behavior jaeger is disabled

Actual behavior The value contained with application.properties is used.

To Reproduce create a quarkus project add the opentracing extension build the executable jar or native image start with -Dquarkus.jaeger.enabled=false observe that the tracer is created and proceeds with tracing

Environment (please complete the following information):

• Output of uname -a or ver: Darwin USMACEA013SSCOT 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64
• Output of java -version: openjdk version “11.0.3” 2019-04-16 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.3+7) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.3+7, mixed mode, sharing)
• GraalVM version (if different from Java):
• Quarkus version or git rev: 1.0.0.CR1

[dmlloyd]

@dmlloyd I was afraid that you answer this …

Regarding #5387 I’m not comfortable with changing RUN_TIME to BUILD_TIME config even if it fixes the bug as your fix changes the intent of the developer. I understand that you cannot make it works as expected easily, maybe you should open followup issue for the extension maintainer to have a look and, if possible, make it works as intended (so at runtime).

Unfortunately it’s going to start being an error to access run time config from a build step (unless it’s just to proxy the object in to a recorder). If you do want to fix it before #5387 is merged, I understand.

We also use this construct heavily inside the security extension to be able to switch implementation from JDBC/OAuth2/Properties at runtime … we thought … as it is mainly used to switch between dev mode and prod mode we didn’t detect that it was an error 😦. So there should be a lot more issues like this when we think that something is configurable at runtime but it is only configurable at build time and devmode/testmode …

We always should have had a strict check for this, however we also wanted to be able to send run time config objects in to recorders so they need to be proxied to do that.

I think we should instead support injecting run time config objects directly into recorders, and then completely disallow usage of run time config objects in build steps. In fact I’ll file an issue to that effect.

[dmlloyd]

Right it only appears to work, it doesn’t actually work. If you change the flag at run time it has no effect. My PR #5387 simply formalizes the existing, actual behavior by marking this property as a build time property.