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 > > >
