danny0405 commented on code in PR #19784:
URL: https://github.com/apache/hudi/pull/19784#discussion_r3910713271
##########
hudi-io/src/main/java/org/apache/hudi/common/util/ReflectionUtils.java:
##########
@@ -132,26 +132,30 @@ public static Stream<String>
getTopLevelClassesInClasspath(Class<?> clazz) {
ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
String packageName = clazz.getPackage().getName();
String path = packageName.replace('.', '/');
- Enumeration<URL> resources = null;
try {
- resources = classLoader.getResources(path);
+ return Collections.list(classLoader.getResources(path)).stream()
+ .map(ReflectionUtils::toDirectory)
Review Comment:
[P2] Preserve JAR-backed package resources
Every non-test caller of this method is a `packaging/*-bundle/Main`, but
this pipeline drops every `jar:` resource because `new File(jarUri)` is
unsupported. The targeted reactor test actually logged this for
`jar:file:.../hudi-io-1.3.0-SNAPSHOT-tests.jar!/org/apache/hudi/common/util`
and still passed only because the same package was also available from exploded
`target/classes`; a launched shaded bundle has no such fallback, so its `Main`
prints no discovered classes. Could we scan `JarURLConnection`/`JarFile`
entries (or otherwise define file-only behavior) and add a regression test
whose package is available only from a JAR-backed class loader?
--
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]
