davidradl commented on code in PR #25656:
URL: https://github.com/apache/flink/pull/25656#discussion_r1901618852


##########
flink-table/flink-table-api-java/src/main/java/org/apache/flink/table/api/internal/TableEnvironmentImpl.java:
##########
@@ -1029,6 +1029,11 @@ private TableResultInternal executeInternal(
                         defaultJobName,
                         jobStatusHookList);
         try {
+            // Current context class loader here is the application class 
loader.

Review Comment:
   @afedulov you raise a very valid concern. I got me thinking whether existing 
options might resolve this without the need for a potentially regressing code 
change. 
   
   -  
[https://nightlies.apache.org/flink/flink-docs-master/docs/ops/debugging/debugging_classloading/](https://nightlies.apache.org/flink/flink-docs-master/docs/ops/debugging/debugging_classloading/)
 mentions 
[yarn.classpath.include-user-jar](https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/config/#yarn-classpath-include-user-jar)
 . 
   - I see 
[[yarn.classpath.include-user-jar](https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/config/#yarn-classpath-include-user-jar)]([yarn.classpath.include-user-jar](https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/config/#yarn-classpath-include-user-jar))
   with options 
[classloader.parent-first-patterns.default](https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/config/#classloader-parent-first-patterns.default)
 and 
[classloader.parent-first-patterns.additional](https://nightlies.apache.org/flink/flink-docs-master/docs/deployment/config/#classloader-parent-first-patterns.additional).
   - I see 
[https://nightlies.apache.org/flink/flink-docs-master/docs/ops/debugging/debugging_classloading/#avoiding-dynamic-classloading-for-user-code](https://nightlies.apache.org/flink/flink-docs-master/docs/ops/debugging/debugging_classloading/#avoiding-dynamic-classloading-for-user-code)
 . Can we put the jar file in `lib` and avoid the dynamic class load?
   
   
   Also looking at the fix again - does this mean that we no longer get access 
to any content from the user class loader, as we have replaced it with a 
different class loader in the parameter now?
   
   
   
   
   



-- 
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: issues-unsubscr...@flink.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to