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 Fri, 10 Mar 2017 16:28:32 GMT
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 <jeff@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
> jeff@greenqloud.com
> www.greenqloud.com
>
> On Fri, Mar 10, 2017 at 2:38 PM, Rafael Weingärtner <
> rafaelweingartner@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 <jeff@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
> > > 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
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>



-- 
Rafael Weingärtner

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