Hey @steffan can you please consider https://github.com/steffan-westcott/clj-otel/pull/30? thank you!
@ericdallo I see that ECA is using clj-otel 0.2.10, which I assume is working OK with native-image. FYI I've just pushed an alternative fix that uses native-image.properties with this https://github.com/steffan-westcott/clj-otel/commit/6ef4cf2ab1c2e3e13ca7a79d6f8deda2b8af3fc4. I tested this with ECA's native-cli build target, it seems to compile OK.
Yes @steffan, no issues with latest stable! Interesting, I may switch to that after available as a release, thank you!
FYI @r0man
@ericdallo I added delay to various places in clj-otel in response to your earlier messages on GraalVM compatibility (see https://github.com/steffan-westcott/clj-otel/commit/7a3a0088123fdb12d597f77d470e48de5d651ece and https://github.com/steffan-westcott/clj-otel/commit/7d65d89f3a3948560682faa8ac3235c3fca5bff5). To test these changes, I also added a native build target (see https://github.com/steffan-westcott/clj-otel/commit/5f25d23889a7ab74ad927d7e7636a151c5e88819). As far as I understand, there should be no issues with GraalVM compatibility. Have you tested ECA against the latest commit of clj-otel? If it helps, I can push a SNAPSHOT version of clj-otel to Clojars.
Oh, interesting, I'm using 0.2.9, but maybe those delays are not being enough for graal be happy?
But yeah, I'm sorry, I thought delay would be enough but it doesn't seem to be working
I tested them just fine, so I think GraalVM is working OK with delay. Can you show me a build log of the problem?
sure, let me get
To be clear, those delay have been put in after clj-otel 0.2.9 was released
hum, that would explain a lot
https://github.com/editor-code-assistant/eca/actions/runs/18283256459/job/52051385469#step:5:940
so what I checked on master is not what's on 0.2.9, there is no delay
Yes, I put in the fixes after you reported issues. I'm still working on some changes for OpenTelemetry Logs support, but I believe your issues should be resolved when clj-otel 0.2.10 is released.
awesome, makes sense! I need logs support as well on #eca, was about to integrate with otel sdk manually like I did in clojure-lsp, but I guess I will wait for you!
Sorry for the delay (see what I did there?) 😄 I'll try to get clj-otel release 0.2.10 out soon, probably this week.
that's perfect, thank you for your help!
Incidentally, I see you included com.github.steffan-westcott/clj-otel-sdk-extension-autoconfigure, but the code doesn't actually use it.
The way I use that on clojure-lsp and eca is: let user configure otel completly via config, this way I can on my company for example configure to point to my company otel collector
I put in some changes to clj-otel-sdk-extension-autoconfigure , prompted by what your code is doing to override properties defaults. See https://github.com/steffan-westcott/clj-otel/commit/1f67550daedde14df6921292d13136fd6fa80786
I think this use of properties will be OK for now, but perhaps not the best. OpenTelemetry Java has an incubating feature for applying configuration with YAML, rather than system properties. I'm no fan of YAML as a format, but that method of config is likely to be better supported than overriding properties defaults.
oh that's great! this is how we use at nubank for clojure-lsp and eca, I just need any way to configure that like that dynamically if we have this option like you linked, that would be perfect
FYI, the incubating feature I mentioned above is called https://opentelemetry.io/docs/languages/java/configuration/#declarative-configuration. Once it emerges from incubation, I'll examine whether it can be adapted to consume EDN configuration files.
Hum interesting, what bothers me is the need to have one more config file
It's just one option of many when using autoconfiguration.
Yeah, I can see how convenient for others is
Remember, there is also programmatic configuration, which is where clj-otel-* modules help (minus clj-otel-api)