yuqi1129 commented on issue #12164:
URL: https://github.com/apache/gravitino/issues/12164#issuecomment-5069743744
@wsxuehao
Thanks for raising this issue. I may have missed something, but I think the
current code already has a fallback in some cases.
For a class treated as shared, we first try `baseClassLoader.loadClass()`.
If the server cannot find the class, we fall back to `super.loadClass()`, which
can load it from the catalog JAR.
So I think there are two different cases:
1. A new catalog package is missing from `isCatalogClass()`, and the server
does not have this class. In this case, the current fallback should normally
load the class from the catalog JAR.
2. Both the server and the catalog JAR contain the same class, but with
different versions.
In this case, the server class may be loaded first. Since loading succeeds,
there is no exception and no fallback. This may later cause errors such as
`NoSuchMethodError` or `LinkageError`. I agree that child-first loading can
help with this case.
However, I am not sure the proposed code fully supports child-first loading
for catalog-private third-party dependencies. The current `isSharedClass()`
returns true for `!isCatalogClass(name)`, so most third-party classes are still
treated as shared. Changing only `super.loadClass()` in the non-shared branch
may only affect the catalog packages already listed in `isCatalogClass()`.
Could you please clarify which case this issue mainly wants to solve?
- If the goal is to make catalog-private dependencies child-first by
default, I think we may also need to change the class classification rule: keep
a clear list of shared API packages, and use child-first loading for
- other classes. This would be a larger behavior change, so it would also be
helpful to have a test with different dependency versions in the server and
catalog JARs.
--
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]
