Kafka / Avro class loader issue #16810
Comments
|
/cc @cescoffier |
|
This is because when locating the Avro schema of the generated class, Avro tries to load the generated class first from the class loader that loaded Avro itself. Only if that fails does Avro consult the TCCL. In the Quarkus architecture, Avro is loaded by the Quarkus base CL, which has the JDK app CL as a parent -- so it can always find the generated classes, because they are on the JVM classpath. Which means that when Avro tries to load the generated class, which is an application class, it is loaded by the Quarkus base CL, instead of the Quarkus application CL. The generated class is also loaded by the Quarkus app CL, as part of the regular application. So we have it loaded twice, in two different class loaders. More discussion: https://quarkusio.zulipchat.com/#narrow/stream/187038-dev/topic/Avro.20vs.2E.20continuous.20testing |
This prevents the base runtime CL from loading deployment classes. Fixes quarkusio#16810 Fixes quarkusio#16804
This prevents the base runtime CL from loading deployment classes. Fixes quarkusio#16810 Fixes quarkusio#16804
This prevents the base runtime CL from loading deployment classes. Fixes quarkusio#16810 Fixes quarkusio#16804
This prevents the base runtime CL from loading deployment classes. Fixes quarkusio#16810 Fixes quarkusio#16804
This prevents the base runtime CL from loading deployment classes. Fixes quarkusio#16810 Fixes quarkusio#16804
This prevents the base runtime CL from loading deployment classes. Fixes quarkusio#16810 Fixes quarkusio#16804
From quarkusio/quarkus#13154, the `@TestProfile` annotation supports Native tests, therefore the modules 001, 301 and 303 can be extended for Native test coverage. As part of this work, we have supported also the test resources for Native: quarkusio/quarkus#18077 And also, I've removed the workaround for quarkusio/quarkus#16810 that had been fixed a while ago. Moreover, for 301: - We've fixed the native failures and got rid of the application.properties file in the test resources. This can be closed now: quarkusio/quarkus#17829. - Reduce the number of traces to ease the troubleshot of failures. And for 303: - Refactored the test resources to not rely on system properties to load/unload application properties.
From quarkusio/quarkus#13154, the `@TestProfile` annotation supports Native tests, therefore the modules 001, 301 and 303 can be extended for Native test coverage. As part of this work, we have supported also the test resources for Native: quarkusio/quarkus#18077 And also, I've removed the workaround for quarkusio/quarkus#16810 that had been fixed a while ago. Moreover, for 301: - We've fixed the native failures and got rid of the application.properties file in the test resources. This can be closed now: quarkusio/quarkus#17829. - Reduce the number of traces to ease the troubleshot of failures. And for 303: - Refactored the test resources to not rely on system properties to load/unload application properties.
Describe the bug
Suddenly beefy-ts/reactive-kafka stop working. Looks that we have a problem related to class loading order.
Scenario
How to reproduce:
mvn clean test -pl 301-quarkus-vertx-kafkaQuarkus Version: Upstream
Error message:
class io.quarkus.qe.kafka.StockPrice cannot be cast to class org.apache.avro.specific.SpecificRecordPatch: Add the following property to your application.properties
quarkus.test.flat-class-path=trueThe text was updated successfully, but these errors were encountered: