unexpected stacktraces about missing Http1xServerResponse and RecordParserImpl vertx classes in native build #40243
Assignees
Labels
Milestone
Comments
|
/cc @Karm (mandrel), @brunobat (opentelemetry,tracing), @galderz (mandrel), @radcortez (opentelemetry,tracing), @zakkak (mandrel,native-image) |
|
The regression was introduced in Quarkus 3.7 by #37633 It looks like we should make the registration of these classes for re-initialization conditional on their presence or move them to a different processor. |
zakkak
added a commit
to zakkak/quarkus
that referenced
this issue
Apr 24, 2024
Vert.x is not a dependency of netty, meaning that the classes may not always be on the classpath. Fixes quarkusio#40243
zakkak
added a commit
to zakkak/quarkus
that referenced
this issue
Apr 24, 2024
Vert.x is not a dependency of netty, meaning that the classes may not always be on the classpath. Fixes quarkusio#40243 Supersedes quarkusio#40248
|
Thanks @zakkak , tried it out again with last nights snapshot build for main following your fix, stacktraces are gone now. |
|
Great, thanks for reporting the issue and testing the fix @gemmellr ! |
|
Done |
gsmet
pushed a commit
to gsmet/quarkus
that referenced
this issue
Apr 26, 2024
Vert.x is not a dependency of netty, meaning that the classes may not always be on the classpath. Fixes quarkusio#40243 Supersedes quarkusio#40248 (cherry picked from commit c610a8b)
poldinik
pushed a commit
to poldinik/quarkus
that referenced
this issue
Apr 29, 2024
Vert.x is not a dependency of netty, meaning that the classes may not always be on the classpath. Fixes quarkusio#40243 Supersedes quarkusio#40248
gsmet
pushed a commit
to gsmet/quarkus
that referenced
this issue
May 10, 2024
Vert.x is not a dependency of netty, meaning that the classes may not always be on the classpath. Fixes quarkusio#40243 Supersedes quarkusio#40248 (cherry picked from commit c610a8b)
gsmet
pushed a commit
to gsmet/quarkus
that referenced
this issue
May 22, 2024
Vert.x is not a dependency of netty, meaning that the classes may not always be on the classpath. Fixes quarkusio#40243 Supersedes quarkusio#40248 (cherry picked from commit c610a8b)
gsmet
pushed a commit
to gsmet/quarkus
that referenced
this issue
May 22, 2024
Vert.x is not a dependency of netty, meaning that the classes may not always be on the classpath. Fixes quarkusio#40243 Supersedes quarkusio#40248 (cherry picked from commit c610a8b)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When creating an initial project via code.quarkus.io using quarkus-qpid-jms, compiling the project under a native build then produces two stacktraces during the native build, about missing vert.x classes
io.vertx.core.http.impl.Http1xServerResponseandio.vertx.core.parsetools.impl.RecordParserImpl, in apparent attempts to handle runtime-reinitialisation of them.Quarkus-qpid-jms does not itself use vertx (thus why it isnt present), so it isnt clear what specifically is prompting the apparent attempts to handle runtime-reinitialisation of these classes. Things quarkus-qpid-jms does do which look to visibly alter the build command include: enabling https protocol support (for TLS), enabling security services (for some SASL mechs), and depending on quarkus-netty to handle things for native builds. Presumably something around these differences is causing it?
This happens with 3.8.x and 3.9.x, yet did not happen historically (not yet known when it started exactly) and it does not occur on 3.2.x. In this period, quarkus-qpid-jms itself essentially has not changed at all except the version of quarkus used and built against (and the recent graal-sdk -> nativeimage sdk dep switch).
As might be expected, the stacktraces disappear when vertx is present, so e.g the quarkus-qpid-jms tests and quickstart never showed these stacktraces as they all use quarkus-rest[easy-reactive] and thus do bring in the vertx classes.
The native build command + output:
Commenting out the quarkus-qpid-jms extension, leaving just quarkus-arc (and quarkus-junit 5 as a test dep), the native build command alters slightly as discussed previously and it does not produce the same stacktraces during native build, suggesting perhaps one of the differences in the build command or the quarkus-netty dep is causing a side effect in quarkus components that provoke the stacktraces? :
Expected behavior
No stacktraces about missing classes that arent being used by extension.
Actual behavior
2 stacktraces printed about missing classes that aren't being used by extension.
How to Reproduce?
Output of
uname -aorverNo response
Output of
java -versionNo response
Mandrel or GraalVM version (if different from Java)
No response
Quarkus version or git rev
No response
Build tool (ie. output of
mvnw --versionorgradlew --version)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: