I got a reply from Midonet community; they said that midonet-client was incorporated by midonet-cluster ( https://github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster).
So, if anyone wants to invest energy on this, it might be a good idea to upgrade the dependency. Moreover, I start to question the compatibility of the current client we are using, with the mido-net server side that might be deployed by users. Will this partial integration that we have work? On Sat, Mar 11, 2017 at 2:49 AM, Paul Angus <paul.an...@shapeblue.com> wrote: > Jeff, > > To confirm what Rohit said, I spoke with Midokura a couple of years ago, > they did some basics, then were looking for a customer to finish/polish the > implementation with. > > AFAIK that never happened, as customers wanted to see it working FIRST > before signing up. > > Kind regards, > > Paul Angus > > paul.an...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > > -----Original Message----- > From: Jeff Hair [mailto:j...@greenqloud.com] > Sent: 10 March 2017 13:45 > To: dev@cloudstack.apache.org > Subject: Re: midonet-client and Guava dependency conflict > > 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
