I was about to reply along those lines. As you brought it up, we are now considering it. If the fix is easy I'd say let it stay till the next problem but it is ot the first time mido bugs us.
On Thu, Mar 9, 2017 at 5:07 PM, Simon Weller <swel...@ena.com> wrote: > 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 > > > 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 >> -- Daan
