kamisama0002 opened a new issue, #13989:
URL: https://github.com/apache/gravitino/issues/13989
### Version
main branch, tested at `2b41cab63f8b1a4b0b08fed274bf75bfd5a0ce47`. The same
failure also reproduces with the 1.2.0 and 1.3.1 loader implementations.
### Describe what's wrong
`IsolatedClassLoader` captures the thread context classloader (TCCL) as its
shared-class base and reads the TCCL again when choosing its parent during lazy
initialization. If either happens inside another catalog's `withClassLoader`
scope, the new loader can depend on that catalog loader.
After the first loader closes, the second can still return a provider class
defined by it. Calling a method that first resolves another class then fails,
even though the second loader has the required JARs.
### Error message and/or stacktrace
Reproduced with `OSSFileSystemProvider` and hadoop-aliyun:
```text
java.lang.NoClassDefFoundError:
org/apache/hadoop/fs/aliyun/oss/AliyunOSSFileSystem
at
org.apache.gravitino.oss.fs.OSSFileSystemProvider.getFileSystem(OSSFileSystemProvider.java:68)
Caused by: java.lang.ClassNotFoundException:
org.apache.hadoop.fs.aliyun.oss.AliyunOSSFileSystem
```
### How to reproduce
1. Create L1 with a JAR containing a provider under
`org.apache.gravitino.oss` and a dependency used by one of its methods. Load
the provider without calling the method.
2. Inside `L1.withClassLoader(...)`, construct L2 with the same JAR.
3. Close L1. Load the provider through L2 and call the method.
4. L2 returns the provider defined by the closed L1, which cannot load the
dependency. Expected: L2 loads its own provider and the method succeeds.
The pool path also reproduces this: acquire a second entry with a different
key inside the first entry's `withClassLoader` scope, release the first entry,
then use the second. Full resource cleanup runs in this reproduction.
### Additional context
Verified on CentOS Stream 10 with JDK 17. The OSS reproduction uses
synthetic credentials and a local endpoint; it only initializes and closes the
filesystem.
The reproduction covers the loader and pool lifecycles. The production
request path that introduces the nested TCCL still needs tracing. Related
lifecycle fixes: #10480, #12404 and #12987.
--
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]
