[
https://issues.apache.org/jira/browse/FLINK-15635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17018110#comment-17018110
]
Timo Walther commented on FLINK-15635:
--------------------------------------
Hi [~wenlong.lwl], you suggestions make total sense. I don't claim that this
issue fixes all problems around classloading. It is just one refactoring that
helps in the mid-term. In the long-term, I agree that we need to better split
"runtime classes" from "planning classes". For example, for planning we need
the "KafkaTableSourceFactory" to configure a "KafkaTableSource" but this
doesn't mean that we need Kafka already present in the classpath until the
actual runtime. Ideally, the Kafka classes should be loaded in the "open()"
method of source/sink operator on the task manager. Then also the
shading/relocation business would not be necessary anymore. However, I don't
think that these big changes are on the roadmap for the next release. Maybe
Flink 1.12?
> Allow passing a ClassLoader to EnvironmentSettings
> --------------------------------------------------
>
> Key: FLINK-15635
> URL: https://issues.apache.org/jira/browse/FLINK-15635
> Project: Flink
> Issue Type: Improvement
> Components: Table SQL / API, Table SQL / Planner
> Reporter: Timo Walther
> Priority: Major
>
> We had a couple of class loading issues in the past because people forgot to
> use the right classloader in {{flink-table}}. The SQL Client executor code
> hacks a classloader into the planner process by using {{wrapClassLoader}}
> that sets the threads context classloader.
> Instead we should allow passing a class loader to environment settings. This
> class loader can be passed to the planner and can be stored in table
> environment, table config, etc. to have a consistent class loading behavior.
> Having this in place should replace the need for
> {{Thread.currentThread().getContextClassLoader()}} in the entire
> {{flink-table}} module.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
