tillrohrmann commented on a change in pull request #10076:
[FLINK-14465][runtime] Let `StandaloneJobClusterEntrypoint` use user code class
loader
URL: https://github.com/apache/flink/pull/10076#discussion_r343212877
##########
File path:
flink-container/src/main/java/org/apache/flink/container/entrypoint/ClassPathJobGraphRetriever.java
##########
@@ -133,9 +138,18 @@ private String getJobClassNameOrScanClassPath() throws
FlinkException {
}
private String scanClassPathForJobJar() throws IOException {
- LOG.info("Scanning class path for job JAR");
- JarFileWithEntryClass jobJar =
JarManifestParser.findOnlyEntryClass(jarsOnClassPath.get());
-
+ final JarFileWithEntryClass jobJar;
+ if (getUserClassPaths().isEmpty()) {
+ LOG.info("Scanning system class path for job JAR");
+ jobJar =
JarManifestParser.findOnlyEntryClass(jarsOnClassPath.get());
+ } else {
+ LOG.info("Scanning user class path for job JAR");
+ final List<File> userJars = getUserClassPaths()
+ .stream()
+ .map(url -> new File(url.getFile()))
+ .collect(Collectors.toList());
+ jobJar = JarManifestParser.findOnlyEntryClass(userJars);
+ }
Review comment:
Ok, your concern is that the user misconfigured the setup and expects that
something from `xxx.jar` will be loaded even though the jar with the entrypoint
is in `lib`.
If we say that the user jar must be in `usrlib` and it fails if he puts it
in `lib` then we get an inconsistency. The problem is that the user can still
put his user jar in `lib` if he specifies the entrypoint class name. This is
then a somewhat inconsistent behaviour which is weird. In that sense, it would
be more consistent to say that Flink uses either the system or user code
classloader depending where the user code jar is/can be found.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
