Hi Till, Sorry, I understand that this was confusing. The JarWithMain contains a class called Launcher with main method that does something like:
Class.getForName("classFromUserJar").newInstance().launch() So it doesnt have any "static" dependency to the UserJar. JarWithMain has a lot of API classes that UserJar depends on. And you are right, I put the jars in a place where it is accessible from every node. (We have a distributed fs mounted under the same path on each machine) I hope I'm clearer now, but let me know if you need some more info (or you can drop me a line on skype) Gyula Till Rohrmann <trohrm...@apache.org> ezt írta (időpont: 2016. nov. 15., K, 14:55): > Hi Gyula, > > did I understand it correct that JarWithMain depends on UserJar because > the former will execute classes from the latter and UserJar depends on > JarWithMain because it contains classes depending on class from > JarWithMain? This sounds like a cyclic dependency to me. > > The command line help for -C says the following: “Adds a URL to each user > code classloader on all nodes in the cluster. The paths must specify a > protocol (e.g. file://) and be accessible on all nodes (e.g. by means of a > NFS share). You can use this option multiple times for specifying more than > one URL. The protocol must be supported by the {@link > java.net.URLClassLoader}.” > > Thus, I assume that you’ve placed the jar whose classpath you specify via > -C somewhere where it is accessible from all nodes including the one > running the CliFrontend, right? Otherwise running such a job cannot work > because -C won’t distribute the jars in the cluster. > > I tried to reproduce your issue by setting up a multi module where my main > module depends on the user module via dynamic class loading and the user > module depends on the main module by a class dependency. Specifying a > classpath which is accessible from all nodes allows to run the job via > flink/run > -C main -c Job util and flink/run -C util -c Job main where Job is > residing in main. > > Thus, I would need some more information about the actual setup to be able > to reproduce your problem. > > Cheers, > Till > > > On Tue, Nov 15, 2016 at 10:06 AM, Gyula Fóra <gyula.f...@gmail.com> wrote: > > Hi Scott, > > Thanks, I am familiar with the ways you suggested. Unfortunately packaging > everything together is not really an option in our case, we specifically > want to avoid having to do this as many people will set up their own builds > and they will inevitable fail to include everything necessary with the > correct setup. > > Including it in the lib folder would mean I have to copy/remove jars all > the time when deploying new jobs if I don't want to have dependency clashes > and also it doesn't seem to be a clean solution for something so simple. > > I thought the -C option would actually do what I am looking for in an > elegant way that's why I am trying to understand what happened. > > Cheers, > Gyula > > Scott Kidder <kidder.sc...@gmail.com> ezt írta (időpont: 2016. nov. 14., > H, 18:49): > > Hi Gyula, > > I've typically added external library dependencies to my own application > JAR as shaded-dependencies. This ensures that all dependencies are included > with my application while being distributed to Flink Job Manager & Task > Manager instances. > > Another approach is to place these external JARs in the 'lib' > sub-directory of your Flink installation. Keep in mind that the external > JARs must be installed on every Flink node where your application is > expected to run. This works well for dependencies that are large in size or > used by multiple Flink applications in your cluster (avoid duplication of > dependencies). > > Best, > > --Scott Kidder > > On Mon, Nov 14, 2016 at 7:59 AM, Gyula Fóra <gyula.f...@gmail.com> wrote: > > Hi, > > I have been trying to use the -C flag to add external jars with user code > and I have observed some strange behaviour. > > What I am trying to do is the following: > I have 2 jars, JarWithMain.jar contains the main class and UserJar.jar > contains some classes that the main method will eventually execute and also > depends on classes from JarWithMain. > > Running this works: > flink run .... -C UserJar.jar -c MainMethod JarWithMain.jar args... > > Running this leads to no class def found errors in the StreamTask > initialization where it reads the functions from the config: > flink run .... -C JarWithMain.jar -c MainMethod UserJar.jar args... > > Did I miss something? > > Cheers, > Gyula > > > >