cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Hair <j...@greenqloud.com>
Subject Re: midonet-client and Guava dependency conflict
Date Fri, 10 Mar 2017 14:06:37 GMT
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
jeff@greenqloud.com
www.greenqloud.com

On Fri, Mar 10, 2017 at 1:44 PM, Jeff Hair <jeff@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
> 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
>>
>
>

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