hudi-agent commented on code in PR #19596:
URL: https://github.com/apache/hudi/pull/19596#discussion_r3769135060
##########
hudi-common/src/main/java/org/apache/hudi/common/avro/HoodieAvroUtils.java:
##########
@@ -124,6 +125,29 @@ public class HoodieAvroUtils {
private static final Properties PROPERTIES = new Properties();
+ /**
+ * Resolves the Avro library version, preferring Maven's generated
pom.properties over
+ * {@link Package#getImplementationVersion()}. The latter reads the jar
manifest, which is
+ * present for a standalone avro-*.jar but is usually dropped for the avro
package once its
+ * classes are merged into a shaded/fat jar.
+ */
+ private static String resolveAvroVersion() {
+ String avroPomPropertiesPath =
"META-INF/maven/org.apache.avro/avro/pom.properties";
+ try (InputStream inputStream =
Schema.class.getClassLoader().getResourceAsStream(avroPomPropertiesPath)) {
+ if (inputStream != null) {
+ Properties avroProperties = new Properties();
+ avroProperties.load(inputStream);
+ String version = avroProperties.getProperty("version");
+ if (version != null) {
+ return version;
+ }
Review Comment:
🤖 nit: silently swallowing the exception makes it hard to diagnose a
misconfigured classpath in the future — could you at least log at DEBUG/WARN
level (e.g. `LOG.warn("Failed to read avro pom.properties, falling back to
manifest version", e)`) rather than fully ignoring it?
<sub><i>⚠️ AI-generated; verify before applying. React 👍/👎 to flag
quality.</i></sub>
##########
hudi-common/src/main/java/org/apache/hudi/common/avro/HoodieAvroUtils.java:
##########
@@ -124,6 +125,29 @@ public class HoodieAvroUtils {
private static final Properties PROPERTIES = new Properties();
+ /**
+ * Resolves the Avro library version, preferring Maven's generated
pom.properties over
+ * {@link Package#getImplementationVersion()}. The latter reads the jar
manifest, which is
+ * present for a standalone avro-*.jar but is usually dropped for the avro
package once its
+ * classes are merged into a shaded/fat jar.
+ */
+ private static String resolveAvroVersion() {
+ String avroPomPropertiesPath =
"META-INF/maven/org.apache.avro/avro/pom.properties";
+ try (InputStream inputStream =
Schema.class.getClassLoader().getResourceAsStream(avroPomPropertiesPath)) {
+ if (inputStream != null) {
+ Properties avroProperties = new Properties();
+ avroProperties.load(inputStream);
+ String version = avroProperties.getProperty("version");
+ if (version != null) {
+ return version;
+ }
+ }
+ } catch (Exception ignored) {
+ // Ignoring the exception and falling back to the manifest-based version
below
+ }
+ return Schema.class.getPackage().getImplementationVersion();
Review Comment:
🤖 The fallback still returns
`Schema.class.getPackage().getImplementationVersion()`, which is exactly the
value that came back `null` in the reported crash. If `pom.properties` is also
missing (e.g. a bundle that strips `META-INF/maven/**`), `AVRO_VERSION` stays
null and `StringUtils.compareVersions(null, ...)` in
`gteqAvro1_12()`/`gteqAvro1_9()` will still NPE. Would it be worth guarding the
null case here (or in the `gteqAvro*` helpers) so the NPE is eliminated in all
paths rather than just the common one?
<sub><i>⚠️ AI-generated; verify before applying. React 👍/👎 to flag
quality.</i></sub>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
