cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Weingärtner <rafaelweingart...@gmail.com>
Subject Re: midonet-client and Guava dependency conflict
Date Mon, 13 Mar 2017 18:45:53 GMT
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.angus@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.angus@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>
> -----Original Message-----
> From: Jeff Hair [mailto:jeff@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
> jeff@greenqloud.com
> www.greenqloud.com
>
> On Fri, Mar 10, 2017 at 1:34 PM, Rafael Weingärtner <
> rafaelweingartner@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 <jeff@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
> > > jeff@greenqloud.com
> > > www.greenqloud.com
> > >
> > > On Fri, Mar 10, 2017 at 9:25 AM, Rohit Yadav
> > > <rohit.yadav@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 <sweller@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 <jeff@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.yadav@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 <jeff@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message