Hi, Stephan
It is a great change, keep it and polish it. nice nice nice I think the more fewer NoClassDefFoundError or ClassNotFoundException the user will encounter in the future. But I would like to two question about this functionality. If Im am wrong, please helps me out. Thank you in advance. You said : Now, while that is nice, child-first classloading runs into trouble when the application jars are not properly built. Q: Hmm, I think it is seldom to happens as users (like me in some times, but seldom) always debug the application to run correctly on my local machine before they deploy to production environment. If I set the child-first strategy, I can use whatever software (akka, Avro,protobuf) version I want and those software also in flink core is being using and can not cause class conflicts. I am correct ? You said: when the class path has the Kafka Connector (connector is in the lib directory) and the application jar also contains Kafka, the we get nasty errors due to class duplication and impossible class casts (X cannot be cast to X). Q: the class path is what ? flink itself runtime classpath ? (I dont think it is a flink itself runtime classpath), and the application jar ( I think it is the user jar that upload to a flink cluster) Could you tell me more ? Thanks Minglei. At 2018-03-09 19:21:18, "Stephan Ewen" <se...@apache.org> wrote: >Hi all! > >Flink 1.4 introduces child-first classloading by default, for the >application libraries. > >We added that, because it allows applications to use different versions of >many libraries, compared to what Flink uses in its core, or compared to >what other dependencies (like Hadoop) pull into the class path. > >For example, applications can use different versions of akka, Avro, >Protobuf, etc. Compared to what Flink / Hadoop / etc. uses. > >Now, while that is nice, child-first classloading runs into trouble when >the application jars are not properly built, meaning when the application >JAR contains libraries that it should not (because they are already in the >classpath / lib folder). > >For example, when the class path has the Kafka Connector (connector is in >the lib directory) and the application jar also contains Kafka, the we get >nasty errors due to class duplication and impossible class casts (X cannot >be cast to X). > > >What I would like to understand is how this change worked out for the >users. Based on that, we can keep this or revert this change in the next >release. > >Please answer to this mail with: > > a. This was a great change, keep it and polish it. > > b. This caused in the end more problems than it solved, so please set the >default back to "parent-first" in 1.5 and leave "child-first" as an >optional flag. > > >Thanks a lot, >Stephan
