LuciferYang opened a new issue, #7688:
URL: https://github.com/apache/kyuubi/issues/7688
### Description
`DynMethods.Builder` lets a caller choose the loader used for name-based
lookups:
```java
public Builder loader(ClassLoader newLoader) {
this.loader = newLoader;
return this;
}
```
`impl(String className, ...)` honours it:
```java
Class<?> targetClass = Class.forName(className, true, loader);
```
`ctorImpl(String className, ...)` does not. It builds a fresh inner
`DynConstructors.Builder`, whose own `loader` field defaults to
`Thread.currentThread().getContextClassLoader()`, and never forwards the one
configured on the outer builder:
```java
this.method = new DynConstructors.Builder().impl(className,
argClasses).buildChecked();
```
So `.loader(x).ctorImpl("some.Class")` resolves `some.Class` through the
thread context loader rather than through `x`. When the context loader cannot
see the class, `DynConstructors.Builder.impl(String, ...)` swallows the
`ClassNotFoundException` as a candidate miss, and the outer `build()` /
`buildChecked()` then fails with a generic cannot-find error. The configured
loader is ignored without any diagnostic saying so.
This matters in Kyuubi because engine code reflects into classes that are
only visible to a particular loader (a Spark or Flink user classloader, an
isolated engine classloader), and `.loader(...)` is the documented way to name
that loader.
Reproducer:
```java
ClassLoader appLoader = MyClass.class.getClassLoader();
ClassLoader blinded = new URLClassLoader(new URL[0], null);
Thread.currentThread().setContextClassLoader(blinded);
DynMethods.builder("MyClass")
.loader(appLoader) // ignored
.ctorImpl(MyClass.class.getName())
.buildChecked();
// java.lang.NoSuchMethodException: Cannot find method: MyClass
```
Expected: the constructor is found, because `appLoader` can see `MyClass`.
### Affected code
`DynMethods.Builder.ctorImpl(String, Class...)`. The `ctorImpl(Class,
Class...)` overload takes an already-loaded class and its inner lookup only
calls `Class.getConstructor`, so it never reads a loader and is unaffected.
### Upstream
Neither upstream copy forwards the loader either: parquet-common has the
same shape on 1.12.x and on current master, and iceberg-common had it on 0.12.1
before removing `ctorImpl` altogether. Note that `ctorImpl` currently has no
callers inside Kyuubi, so an alternative to fixing it is to follow iceberg and
drop both overloads; that is a maintainer call.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
