Native mode tests for serialization are failing #4148
Comments
jamesnetherton
changed the title
|
@zakkak any ideas on recent changes that may have had an impact on Serialization in native mode? I see some commits related to native that got backported to 2.13.1. |
Most of these commits change behavior only when using GraalVM / Mandrel 22.3 which is not yet released. So they should not affect your tests at this point. The only possibly related change could be quarkusio/quarkus@e363914#diff-7d1388bbdd07a9362ef261153d5cc4cbccd0f5f5f95446ad3f647f9cd38768bcL471-R469 Do I understand correctly that things are working with 2.13.0 but not with 2.13.1 using the same GraalVM / Mandrel version? |
Yes, exactly |
|
OK, could you please provide the steps to reproduce this issue (ideally with the option to use local quarkus builds, as well i.e. |
|
@zakkak try this branch on my fork. It's set up to point at Quarkus You can omit the |
|
I confirm that quarkusio/quarkus@e363914#diff-7d1388bbdd07a9362ef261153d5cc4cbccd0f5f5f95446ad3f647f9cd38768bcL471-R469 is the one causing the regression here but the issue seems to originate from quarkusio/gizmo@091fe32. quarkus-camel registers @Sanne can you please have a look? |
|
@zakkak coul you elaborate on "not getting registered properly" ? What's happening? |
After looking a bit more into it, the issue is the following. When the class name starts with private static void registerClass35(org.graalvm.nativeimage.hosted.Feature.BeforeAnalysisAccess var0) {
try {
Collections.EmptyList.class.getDeclaredConstructors();
Collections.EmptyList.class.getDeclaredMethods();
Collections.EmptyList.class.getDeclaredFields();
Class[] var1 = new Class[]{Collections.EmptyList.class};
RuntimeReflection.register(var1);
registerSerializationForClass(Collections.EmptyList.class);
} catch (Throwable var2) {
}
} However, In contrast when registering a class that is not under private static void registerClass0(org.graalvm.nativeimage.hosted.Feature.BeforeAnalysisAccess var0) {
try {
ClassLoader var1 = Thread.currentThread().getContextClassLoader();
Class var2 = Class.forName("org.apache.commons.pool2.impl.DefaultEvictionPolicy", (boolean)0, var1);
Constructor[] var4 = var2.getDeclaredConstructors();
var2.getDeclaredMethods();
var2.getDeclaredFields();
Class[] var3 = new Class[]{var2};
RuntimeReflection.register(var3);
RuntimeReflection.register((Executable[])var4);
} catch (Throwable var5) {
}
}So I think that we either need to drop the |
|
thanks for the explanation - tricky. Yes I can see how my previous optimisation would break this - but there's also the case for So rather than reverting I think gizmo should be fixed to handle private types correctly whatever the choice of classloader. |
+1 I created quarkusio/quarkus#28431 to track this in Quarkus as well, since it doesn't affect only camel-quarkus. |
|
Could quarkusio/quarkus#12486 (comment) also be related? |
|
@geoand yes: it's a non-public class, and in package |
|
Thanks for confirming @Sanne |
This reverts commit 6b483e8. Fixes apache#4148
This reverts commit 6b483e8. Fixes apache#4148
This reverts commit 6b483e8. Fixes apache#4148
Seems any tests for serialization in native mode are failing with an exception being thrown similar to this one:
Collections.EMPTY_LISTis listed in the core set of classes bound for native serialization support.https://github.com/apache/camel-quarkus/blob/main/extensions-core/core/deployment/src/main/java/org/apache/camel/quarkus/core/deployment/CamelSerializationProcessor.java#L47
The text was updated successfully, but these errors were encountered: