Thanks Alexis, I can give that a try. However, that seems less than ideal from the user's perspective.
Is there a technical reason why the operator can't support this combination of modes? I'd really like to just let the system do its thing rather than build a complicated two-jar approach. Thanks, Trystan On Fri, Nov 17, 2023 at 12:19 PM Alexis Sarda-Espinosa < sarda.espin...@gmail.com> wrote: > 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? >> >
