We have had similar conversations many times recently. Unfortunately we have no way to track IF people are using different plugins, so it makes it really hard to know if people will expect it to be there if they upgrade...
If anyone has ideas for how we can potentially find a way to track that, we should probably start a thread around that. *Will STEVENS* Lead Developer <https://goo.gl/NYZ8KK> On Thu, Mar 9, 2017 at 2:36 PM, Rafael Weingärtner < rafaelweingart...@gmail.com> wrote: > Agree with you, but I think a nice talk with people using it to ask for > help might be a good idea. > > Sometimes they are not aware of these situations. > > On Thu, Mar 9, 2017 at 2:23 PM, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: > > > If we have to lay a burdon of fixing before release on people that > > don't use it, i would say no. You use it, you maintain it. I am happy > > to charge money to whoever wants to not maintain what they use. > > > > On Thu, Mar 9, 2017 at 7:11 PM, Rafael Weingärtner > > <rafaelweingart...@gmail.com> wrote: > > > Daan, before removing anything, I think we should check if there are > > people > > > using it, right? > > > > > > On Thu, Mar 9, 2017 at 11:08 AM, Daan Hoogland < > daan.hoogl...@gmail.com> > > > wrote: > > > > > >> 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 > > >> > > > > > > > > > > > > -- > > > Rafael Weingärtner > > > > > > > > -- > > Daan > > > > > > -- > Rafael Weingärtner >
