Great that you tried removing the dependencies inside the jar. In my opinion this is the way to go. I do not understand why they do not offer a version of the client jar without being bundled with all of its dependencies.
I was doing some checking, this jar is not in Maven central repo. We are adding their repository to download the jar. I asked on their slack channel about a version of their jars without any dependencies, but had no answers. Also, I did not find this client project on Github, though. On Fri, Mar 10, 2017 at 9:48 AM, Jeff Hair <j...@greenqloud.com> wrote: > Yes, I already confirmed removing the guava classes from the Midonet jar > works. Did that yesterday. I can't find any updated version of the jar on > their cs-maven repository. The only one is 1.1.0. > > *Jeff Hair* > Technical Lead and Software Developer > > Tel: (+354) 415 0200 > j...@greenqloud.com > www.greenqloud.com > > On Fri, Mar 10, 2017 at 2:38 PM, Rafael Weingärtner < > rafaelweingart...@gmail.com> wrote: > > > Have you thought/tried to be a bit more brute with this situation? Like > > hammering the Midonet jar and removing the guava classes from it. > > > > > > > > This idea of packaging libraries into a jar may cause these problems > > because Maven will not be able to solve dependencies conflicts. Have we > > checked if Midonet has a package without being bundled with its > > dependencies? > > > > > > > > On Fri, Mar 10, 2017 at 9:06 AM, Jeff Hair <j...@greenqloud.com> wrote: > > > > > After forcing the midonet jar to the end of the classpath, the error > > still > > > comes up. This means that the ordered classloader is being overridden, > or > > > this problem is not solvable simply by changing classpath order. On an > > > important note, when running the simulator through embedded Jetty, this > > > does not happen. The OOBSerivceManagerImpl gets started before midonet, > > and > > > loads its Equivalence.class from guava-19.0.jar. I'm guessing I'm > dealing > > > with some incorrect Tomcat configuration, despite my ordered > classloader. > > > > > > *Jeff Hair* > > > Technical Lead and Software Developer > > > > > > Tel: (+354) 415 0200 > > > j...@greenqloud.com > > > www.greenqloud.com > > > > > > On Fri, Mar 10, 2017 at 1:44 PM, Jeff Hair <j...@greenqloud.com> > wrote: > > > > > > > The Midonet jar has Guava 18 packaged into it with the Shade plugin. > > > > Guava-19.0 is also on the classpath. But for whatever > > > > reason, com.google.common.base.Equivalence is being loaded from the > > > > Midonet jar instead of guava-19.0.jar, even with an alphabetically > > sorted > > > > classpath. This causes the error mentioned in the original message. > My > > > next > > > > step is to figure out if this is just what happens when CS 4.9 is > > running > > > > on Tomcat 8 (my current guess), or if it's some weird interaction > with > > > > changes we've made on our fork (don't see how it can be the case, but > > > must > > > > try all possibilities). Guava 19.0 is coming in as a transitive > > > dependency > > > > of Reflections 0.9.10. This version was set in commit bb29b1d06. > > > > > > > > *Jeff Hair* > > > > Technical Lead and Software Developer > > > > > > > > Tel: (+354) 415 0200 > > > > j...@greenqloud.com > > > > www.greenqloud.com > > > > > > > > On Fri, Mar 10, 2017 at 1:34 PM, Rafael Weingärtner < > > > > rafaelweingart...@gmail.com> wrote: > > > > > > > >> Are these Guava classes in the Midonet jar? Or do you have two jars > > for > > > >> the > > > >> same library with two different version in the lib folder? > > > >> > > > >> On Fri, Mar 10, 2017 at 8:32 AM, Jeff Hair <j...@greenqloud.com> > > wrote: > > > >> > > > >> > I have managed to confirm with advanced debugging techniques (i.e. > > > >> sticking > > > >> > log statements everywhere) that the classloader which sorts the > jars > > > is > > > >> > working as expected, but the error with guava is still popping up. > > My > > > >> next > > > >> > step is to see if there is some overriding of the sorted classpath > > > >> loader. > > > >> > > > > >> > *Jeff Hair* > > > >> > Technical Lead and Software Developer > > > >> > > > > >> > Tel: (+354) 415 0200 > > > >> > j...@greenqloud.com > > > >> > www.greenqloud.com > > > >> > > > > >> > On Fri, Mar 10, 2017 at 9:25 AM, Rohit Yadav < > > > rohit.ya...@shapeblue.com > > > >> > > > > >> > wrote: > > > >> > > > > >> > > +1 Retire unsupported plugins, with at least comment them from > the > > > >> > default > > > >> > > build/packaging in plugins/pom.xml? > > > >> > > > > > >> > > > > > >> > > Several plugins in 'plugins/network-elements/' may be removed > from > > > the > > > >> > > default build/packaging. However, 'midonet' was never fully > > > >> implemented > > > >> > or > > > >> > > completed and most definitely removed. > > > >> > > > > > >> > > > > > >> > > Regards. > > > >> > > > > > >> > > ________________________________ > > > >> > > From: Simon Weller <swel...@ena.com> > > > >> > > Sent: 09 March 2017 21:37:08 > > > >> > > To: dev@cloudstack.apache.org > > > >> > > Subject: Re: midonet-client and Guava dependency conflict > > > >> > > > > > >> > > So this brings up a good discussion point. As Jeff points out, > the > > > >> > Midonet > > > >> > > plugin hasn't been actively supported for almost 5 years. At > what > > > >> point > > > >> > do > > > >> > > we consider retiring unsupported plugins? > > > >> > > > > > >> > > > > > >> > > - Si > > > >> > > > > > >> > > > > > >> > > ________________________________ > > > >> > > From: Jeff Hair <j...@greenqloud.com> > > > >> > > Sent: Thursday, March 9, 2017 9:43 AM > > > >> > > To: dev@cloudstack.apache.org > > > >> > > Subject: Re: midonet-client and Guava dependency conflict > > > >> > > > > > >> > > After doing some more digging, I have confirmed the following: > > > >> > > > > > >> > > - The midonet plugin is using the Maven Shade plugin to put a > > > >> bunch of > > > >> > > dependencies into itself. > > > >> > > - The plugin hosted in this repository was last updated in > > 2013. > > > >> > > - Most importantly: removing all the guava stuff out of the > > > midonet > > > >> > > plugin fixes this issue. > > > >> > > > > > >> > > I have not had any success in applying > > > >> > > https://github.com/openwide-java/tomcat-classloader-ordered to > > get > > > >> > Tomcat > > > >> > > [https://avatars1.githubusercontent.com/u/1385131?v=3&s=400 > > > ]<https:// > > > >> > > github.com/openwide-java/tomcat-classloader-ordered> > > > >> > > > > > >> > > GitHub - openwide-java/tomcat-classloader-ordered: A ...< > > > >> > > https://github.com/openwide-java/tomcat-classloader-ordered> > > > >> > > github.com > > > >> > > README.md tomcat-classloader-ordered. A classloader for Apache > > > Tomcat > > > >> 8 > > > >> > > which loads the jars of WEB-INF lib in alphabetical order. Prior > > to > > > >> > version > > > >> > > 8, Apache Tomcat ... > > > >> > > > > > >> > > > > > >> > > > > > >> > > to load its jars in alphabetical order, for whatever reason. I > > tried > > > >> > > putting the Loader in various context definition locations, but > it > > > >> > refuses > > > >> > > to work. Any ideas? > > > >> > > > > > >> > > Jeff > > > >> > > > > > >> > > > > > >> > > > > > >> > > rohit.ya...@shapeblue.com > > > >> > > www.shapeblue.com > > > >> > > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > > > >> > > @shapeblue > > > >> > > > > > >> > > > > > >> > > > > > >> > > On Thu, Mar 9, 2017 at 1:43 PM, Jeff Hair <j...@greenqloud.com> > > > >> wrote: > > > >> > > > > > >> > > > Hi, > > > >> > > > > > > >> > > > I'm deploying 4.9.2.0 (not the vanilla version, but rather an > > > >> upgraded > > > >> > > > version of our fork) on Tomcat 8. Management server startup > > fails > > > >> with > > > >> > > the > > > >> > > > following error: > > > >> > > > > > > >> > > > java.lang.IncompatibleClassChangeError: Found interface > > > >> > > > com.google.common.base.Equivalence, but class was expected > > > >> > > > > > > >> > > > I've traced this down to the OutOfBandServiceManagerImpl. More > > > >> > > > specifically, when it tries to build the hostAlertCache using > > > >> Guava's > > > >> > > > CacheBuilder. Deep in Guava, it's calling an "identity()" > method > > > on > > > >> the > > > >> > > > Equivalence class. All of the Guava classes are coming from > > > >> guava-19.0 > > > >> > > > except for com/google/common/base/Equivalence.class. The > > > >> Equivalence > > > >> > > > class is being loaded from the midonet jar for some reason, > and > > > that > > > >> > > > version does not have the method needed. Thus, the error. > > > >> > > > > > > >> > > > This is because Tomcat apparently does not load jars in > > > alphabetical > > > >> > > order > > > >> > > > anymore, starting with version 8. An open ticket for them to > fix > > > >> this > > > >> > is > > > >> > > > here: https://bz.apache.org/bugzilla/show_bug.cgi?id=57129 > > > >> > > 57129 – Regression. Load WEB-INF/lib jarfiles in ...< > > > >> > > https://bz.apache.org/bugzilla/show_bug.cgi?id=57129> > > > >> > > bz.apache.org > > > >> > > ASF Bugzilla – Bug 57129 Regression. Load WEB-INF/lib jarfiles > in > > > >> > > alphabetical order Last modified: 2016-03-17 09:59:50 UTC > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > >> > > > It could be possible to "fix" this by using a custom > ClassLoader > > > to > > > >> > force > > > >> > > > Tomcat to load things alphabetically (testing that right > > now--and > > > >> not > > > >> > > > really succeeding), but the proper fix is to have the midonet > > > client > > > >> > not > > > >> > > be > > > >> > > > packaging guava with itself. Does anyone know why this is? > > > >> > > > > > > >> > > > Jeff > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Rafael Weingärtner > > > >> > > > > > > > > > > > > > > > > > > > -- > > Rafael Weingärtner > > > -- Rafael Weingärtner
