You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@hudi.apache.org by GitBox <gi...@apache.org> on 2022/11/04 14:49:59 UTC
[GitHub] [hudi] xushiyan commented on a diff in pull request #6522: [minor]The Kryo of Hudi conflicts with the Kryo of Flink
xushiyan commented on code in PR #6522:
URL: https://github.com/apache/hudi/pull/6522#discussion_r1014118759
##########
hudi-common/src/main/java/org/apache/hudi/common/util/SerializationUtils.java:
##########
@@ -117,7 +117,9 @@ public Kryo newKryo() {
// ensure that kryo doesn't fail if classes are not registered with kryo.
kryo.setRegistrationRequired(false);
// This would be used for object initialization if nothing else works out.
- kryo.setInstantiatorStrategy(new Kryo.DefaultInstantiatorStrategy(new StdInstantiatorStrategy()));
+ Kryo.DefaultInstantiatorStrategy instantiatorStrategy = new Kryo.DefaultInstantiatorStrategy();
+ instantiatorStrategy.setFallbackInstantiatorStrategy(new StdInstantiatorStrategy());
+ kryo.setInstantiatorStrategy(instantiatorStrategy);
// Handle cases where we may have an odd classloader setup like with libjars
Review Comment:
> yes,now we use hudi-flink,and the hudi only needs to modify the code and does not need to use the bundle jar
@cuibo01 can you clarify the situation please? do you mean hudi flink bundle jar will have kryo lib conflicts? we have shaded kryo for every module
https://github.com/apache/hudi/blob/b2a84eed02e52a75b61579398f49ae72eeb01440/pom.xml#L450
--
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: commits-unsubscribe@hudi.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org