[ 
https://issues.apache.org/jira/browse/FLINK-29288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783806#comment-17783806
 ] 

Trystan commented on FLINK-29288:
---------------------------------

Thank you! This is exactly what we are trying to do. I thought we had tested 
this, but clearly it's working for you! No other special incantations - simply 
putting the job jar in the classpath is enough?

 

The documentation here does suggest it is required: 
[https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main/docs/custom-resource/overview/#application-deployments.]
 I assume it must just be out of date if it's working for you :)

> 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
>              Labels: pull-request-available
>             Fix For: kubernetes-operator-1.2.0
>
>
> 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)

Reply via email to