You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SchemaAssistant tracks all the jars that the generated code will need on the classpath, including the classes for all logical types. However, it neglects to track the classes that represent logical types derived from fixed types. Whenever a logical type is represented by a class not in the Java SDK and not in the same jar as its Conversion class, compilation will fail because the class can't be found.
This is an example of a runtime error in the logs.
/tmp/generated1750127073899966702/com/linkedin/avro/fastserde/generated/serialization/AVRO_1_11/ExerciseLogicalTypes_GenericSerializer_1478679821.java:33: error: cannot access UID
convertedValue0 = Conversions.convertToRawType(convertedValue0, this.logicalTypeSchema__692588075, this.logicalTypeSchema__692588075 .getLogicalType(), this.conversion_uid);
^
class file for org.example.logging.UID not found
Note: /tmp/generated1750127073899966702/com/linkedin/avro/fastserde/generated/serialization/AVRO_1_11/ExerciseLogicalTypes_GenericSerializer_1478679821.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
1 error
2024-11-19 17:48:56.752 [ERROR] 1885108 --- [ompile-thread-1] m.linkedin.avro.fastserde.FastSerdeCache : Serializer class instantiation exception
The text was updated successfully, but these errors were encountered:
As I look at this more, I suspect the failure is not confined to fixed types. My use case just happened to be a fixed type, which follows a different code path through SchemaAssistant.classFromSchema. But I believe this error could be reproduced for any logical type where the Java converted type and the Conversion class are in separate jars from each other. If they happen to be in the same jar, which is frequently the case, then the scan for import statements will find the Conversion class and pull in both classes. The attached fix will still resolve the problem for all logical types.
The
SchemaAssistant
tracks all the jars that the generated code will need on the classpath, including the classes for all logical types. However, it neglects to track the classes that represent logical types derived fromfixed
types. Whenever a logical type is represented by a class not in the Java SDK and not in the same jar as itsConversion
class, compilation will fail because the class can't be found.This is an example of a runtime error in the logs.
The text was updated successfully, but these errors were encountered: