[
https://issues.apache.org/jira/browse/FLINK-29288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17603817#comment-17603817
]
Yaroslav Tkachenko commented on FLINK-29288:
--------------------------------------------
Apparently removing *pipeline.jars* is not enough, because the operator will
always create */opt/flink/usrlib* folder on the jobmanager as a volume mount.
This forces Flink's DefaultPackagedProgramRetriever to try using *usrlib*
folder for loading classes (which is empty in this case).
So, in my mind, operator's *UserLibMountDecorator* should only be used when
*jarURI* is specified.
> Can't start a job with a jar in the system classpath
> ----------------------------------------------------
>
> Key: FLINK-29288
> URL: https://issues.apache.org/jira/browse/FLINK-29288
> Project: Flink
> Issue Type: Bug
> Components: Kubernetes Operator
> Affects Versions: kubernetes-operator-1.1.0
> Reporter: Yaroslav Tkachenko
> Priority: Major
>
> I'm using the latest (unreleased) version of the Kubernetes operator.
> It looks like currently, it's impossible to use it with a job jar file in the
> system classpath (/opt/flink/lib). *jarURI* is required and it's always
> passed as a *pipeline.jars* parameter to the Flink process. In practice, it
> means that the same class is loaded twice: once by the system classloader and
> another time by the user classloader. This leads to exceptions like this:
> {quote}java.lang.LinkageError: loader constraint violation: when resolving
> method 'XXX' the class loader org.apache.flink.util.ChildFirstClassLoader
> @47a5b70d of the current class, YYY, and the class loader 'app' for the
> method's defining class, ZZZ, have different Class objects for the type AAA
> used in the signature
> {quote}
> In my opinion, jarURI must be made optional even for the application mode. In
> this case, it's assumed that it's already available in the system classpath.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
