Hi Trystan, I imagine you can create 2 jars, one should only have a class with the main method, and the other should be a fat jar with everything else for your job. If you create a custom image where your fat jar is placed under /opt/flink/lib/ then I think it would "just work" when specifying the main-method jar in jarURI.
Nevertheless, even though Flink shadows a lot of the libraries they use internally, I suppose you could still end up with dependency conflicts, so you would probably have some added complexity managing what's bundled in your fat jar. Regards, Alexis. Am Do., 16. Nov. 2023 um 19:42 Uhr schrieb Trystan <entro...@gmail.com>: > Is it possible to avoid dynamic classloading when using the operator with > a native kubernetes application deployment? > > If I put the job jar into /opt/flinklib, then there are two possible > outcomes: > > 1. If I point jarURI to the jar, I get linkage errors (presumably: the > class have already been loaded by the AppClassLoader and the > FlinkUserCodeClassLoader). > 2. If I do not include jarURI the operator pods encounter a > NullPointerException. The docs state this is optional, but appears to only > pertain to standalone mode. > > https://issues.apache.org/jira/browse/FLINK-29288 enabled the optional > jarURI (apparently only for standalone deployments). > > Are there any additional configurations (configs, jar locations, etc) that > are needed to avoid dynamic classloading in this case? >
