Open dmlloyd opened 3 days ago
/cc @brunobat (opentelemetry), @radcortez (opentelemetry)
@dmlloyd when you say in theory
did you test this particular example?
I tested it obliquely, but I couldn't test it exactly (yet?) due to local configuration problems.
@MaxFichtelmann can you build this PR locally and confirm that it fixes your issue before we merge it?
It makes sense to me even if it doesn't fix the bug.
@MaxFichtelmann can you build this PR locally and confirm that it fixes your issue before we merge it?
Sure, I'll build and Test when I am at the PC again.
Quarkus CI
This is the status report for running Quarkus CI
on commit 8fe3c761a6d77c96686f7e4ac5492876b3353664.
:white_check_mark: The latest workflow run for the pull request has completed successfully.
It should be safe to merge provided you have a look at the other checks in the summary.
You can consult the Develocity build scans.
hm, still seeing that behaviour in quarkus dev
- actually when running that same project without dev, the issue does not appear, neither with 3.14.3 nor 3.16.3 - so seems to be a devmode-only issue.
I also opened https://github.com/jboss-logging/jboss-logmanager/pull/493 which should address what we're seeing on the stack trace, once that is merged & the component is updated.
I'd recommend to wait until https://github.com/jboss-logging/jboss-logmanager/pull/493 is merged and released and updated in this PR before merging
I don't think waiting is necessary, because the two changes are not interdependent.
@dmlloyd sorry if it's just noise but how will the new patch in JBoss Logmanager interact with this specific piece:
where we add parameters to something that used to be NO_FORMAT
.
@dmlloyd I know, but the second change will fix the bug, right?
It might :-)
Loving the confidence behind this patch :D
@dmlloyd sorry if it's just noise but how will the new patch in JBoss Logmanager interact with this specific piece:
7e6c529#diff-3027189c5073a902729f033232338719972cd18a3c64018f24b99dd78e1fea6aR441-R447
where we add parameters to something that used to be
NO_FORMAT
.
The interaction should be fine. The handler for NO_FORMAT
here will change it to use message format, with two arguments.
The interaction should be fine. The handler for NO_FORMAT here will change it to use message format, with two arguments.
And it won't fail if we end up with My message {
that used to work in NO_FORMAT
but won't work with message format? Or maybe you don't resolve the parameters recursively?
The interaction should be fine. The handler for NO_FORMAT here will change it to use message format, with two arguments.
And it won't fail if we end up with
My message {
that used to work inNO_FORMAT
but won't work with message format? Or maybe you don't resolve the parameters recursively?
The original message is passed as a parameter to a new message, so no further interpolation can take place.
OK, perfect, thanks for the clarification. I'm still a bit puzzled the OP says it's failing only in dev mode but I wonder if he actually used the newly compiled version in dev mode, I will have to check that.
OK, perfect, thanks for the clarification. I'm still a bit puzzled the OP says it's failing only in dev mode but I wonder if he actually used the newly compiled version in dev mode, I will have to check that.
I am optimistic that I used the updated version, but this is the first time I built quarkus myself, so...
Fixes #44540 (in theory)