Just to refine Jinmei's answer a little bit; as jars are deployed they create a hierarchy of classloaders so there is a 'direction' of class resolution. If class A depends on B (A->B) then B must be deployed before OR at the same time as A.
--Jens On Fri, Aug 9, 2019 at 5:13 AM Jinmei Liao <jil...@pivotal.io> wrote: > Alberto, what you see is the expected behavior. Jars with dependencies > have to be deployed together, otherwise, they get loaded by different class > loaders, and one can't recognize the other. I believe this was the > restriction we put on deployed jars in order to avoid eager loading of all > the classes in the deployed jars. > > If you bounce the servers, all the jars are loaded together at server > restart time, so you won't get the exception anymore. > > On Fri, Aug 9, 2019 at 4:16 AM Alberto Gomez <alberto.go...@est.tech> > wrote: > >> Hi, >> >> We have two jar files one containing a Geode function and another one >> containing some class used by the function in its execute method. >> >> We have observed the following behavior: >> >> If we load on a Geode cluster one jar and then the other (on any order) >> with gfsh and then call the function from a client, the function is >> executed correctly. >> >> But, if we first load the jar containing the function, call the function >> from a client (in which we get a java.lang.NoClassDefFoundError >> exception for the class referenced), load the other jar containing the >> class used by the function and then call the function we still get the >> same exception. >> >> If the servers are restarted afterwards the problem disappears. >> >> The Geode version we are using is the one found in the development >> branch last week. >> >> Is there an explanation for this behavior or is this a bug? >> >> Thanks in advance, >> >> -Alberto G >> >> >> > > -- > Cheers > > Jinmei >
