Re: midonet-client and Guava dependency conflict

[Rafael Weingärtner]

This is why I suggested a discussion and then a vote. I know the idea of
removing a plugin may seem ignorant, but in my opinion, a code that does
not work, no one maintains, and we hear that never worked 100%, is not a
code worth to have in the code base.  My specific problem with this is that
it gives hope that may work in some situation, or that we may fix it one
day (without support); maybe I am just an old soul that have been so many
times frustrated with software that promised the moon and did not deliver
it.

Having said that, tonight I will start a discussion thread.
Hope to hear you all there.

On Tue, Mar 14, 2017 at 2:49 PM, Daan Hoogland <daan.hoogl...@shapeblue.com>
wrote:

> I think removing the plugin build is friendly to the daring and won’t
> hinder the ignorant. Good call. However; less code always gets my vote as
> well. Conclusion I’m +/- 0 on this.
>
> On 14/03/17 19:43, "Rafael Weingärtner" <rafaelweingart...@gmail.com>
> wrote:
>
> So, should we move to other thread to discuss and vote its removal or
> disable its plugin build?
>
> On Tue, Mar 14, 2017 at 10:49 AM, Daan Hoogland <
> daan.hoogl...@shapeblue.com
> > wrote:
>
> > Well, if Midokura is not willing to put in effort, ... Not sure what
> to
> > put on the dots.
> >
> > On 14/03/17 15:08, "Simon Weller" <swel...@ena.com> wrote:
> >
> > We took a look at testing it in the lab back in early 2016  and
> > Midokura told us that it was a bad idea, probably wouldn't work and
> we
> > should just switch to openstack.
> >
> >
> > - Si
> >
> > ________
> > From: Erik Weber <terbol...@gmail.com>
> > Sent: Tuesday, March 14, 2017 3:28 AM
> > To: dev
> > Subject: Re: midonet-client and Guava dependency conflict
> >
> > On Mon, Mar 13, 2017 at 7:45 PM, Rafael Weingärtner
> > <rafaelweingart...@gmail.com> wrote:
> > > I got a reply from Midonet community; they said that
> midonet-client
> > was
> > > incorporated by midonet-cluster (
> > > https://github.com/midonet/midonet/tree/staging/v5.4/
> midonet-cluster
> > ).
> > [https://avatars2.githubusercontent.com/u/9136532?v=3=400
> ]<https://
> > github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster>
> >
> > midonet/midonet<https://github.com/midonet/midonet/
> > tree/staging/v5.4/midonet-cluster>
> > github.com
> > midonet - MidoNet is an Open Source network virtualization
> system for
> > Openstack clouds
> >
> >
> >
> > >
> > >
> > > So, if anyone wants to invest energy on this, it might be a
> good
> > idea to
> > > upgrade the dependency. Moreover, I start to question the
> > compatibility of
> > > the current client we are using, with the mido-net server side
> that
> > might
> > > be deployed by users. Will this partial integration that we
> have
> > work?
> >
> >
> > Just as important to ask: "Has it ever worked?"
> > Do we know anyone who use, or have used, this integration?
> >
> > --
> > Erik
> >
> >
> >
> > daan.hoogl...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>
>
> --
> Rafael Weingärtner
>
>
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>


-- 
Rafael Weingärtner

Re: midonet-client and Guava dependency conflict

[Daan Hoogland]

I think removing the plugin build is friendly to the daring and won’t hinder 
the ignorant. Good call. However; less code always gets my vote as well. 
Conclusion I’m +/- 0 on this.

On 14/03/17 19:43, "Rafael Weingärtner" <rafaelweingart...@gmail.com> wrote:

So, should we move to other thread to discuss and vote its removal or
disable its plugin build?

On Tue, Mar 14, 2017 at 10:49 AM, Daan Hoogland <daan.hoogl...@shapeblue.com
> wrote:

> Well, if Midokura is not willing to put in effort, ... Not sure what to
> put on the dots.
>
> On 14/03/17 15:08, "Simon Weller" <swel...@ena.com> wrote:
>
> We took a look at testing it in the lab back in early 2016  and
> Midokura told us that it was a bad idea, probably wouldn't work and we
> should just switch to openstack.
>
>
> - Si
>
> 
> From: Erik Weber <terbol...@gmail.com>
    >     Sent: Tuesday, March 14, 2017 3:28 AM
> To: dev
> Subject: Re: midonet-client and Guava dependency conflict
>
> On Mon, Mar 13, 2017 at 7:45 PM, Rafael Weingärtner
> <rafaelweingart...@gmail.com> wrote:
> > I got a reply from Midonet community; they said that midonet-client
> was
> > incorporated by midonet-cluster (
> > https://github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster
> ).
> [https://avatars2.githubusercontent.com/u/9136532?v=3=400]<https://
> github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster>
>
> midonet/midonet<https://github.com/midonet/midonet/
> tree/staging/v5.4/midonet-cluster>
> github.com
> midonet - MidoNet is an Open Source network virtualization system for
> Openstack clouds
>
>
>
> >
> >
> > So, if anyone wants to invest energy on this, it might be a good
> idea to
> > upgrade the dependency. Moreover, I start to question the
> compatibility of
> > the current client we are using, with the mido-net server side that
> might
> > be deployed by users. Will this partial integration that we have
> work?
>
>
> Just as important to ask: "Has it ever worked?"
> Do we know anyone who use, or have used, this integration?
>
> --
> Erik
>
>
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>


-- 
Rafael Weingärtner



daan.hoogl...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: midonet-client and Guava dependency conflict

[Rafael Weingärtner]

So, should we move to other thread to discuss and vote its removal or
disable its plugin build?

On Tue, Mar 14, 2017 at 10:49 AM, Daan Hoogland <daan.hoogl...@shapeblue.com
> wrote:

> Well, if Midokura is not willing to put in effort, ... Not sure what to
> put on the dots.
>
> On 14/03/17 15:08, "Simon Weller" <swel...@ena.com> wrote:
>
> We took a look at testing it in the lab back in early 2016  and
> Midokura told us that it was a bad idea, probably wouldn't work and we
> should just switch to openstack.
>
>
> - Si
>
> 
> From: Erik Weber <terbol...@gmail.com>
>     Sent: Tuesday, March 14, 2017 3:28 AM
> To: dev
> Subject: Re: midonet-client and Guava dependency conflict
>
> On Mon, Mar 13, 2017 at 7:45 PM, Rafael Weingärtner
> <rafaelweingart...@gmail.com> wrote:
> > I got a reply from Midonet community; they said that midonet-client
> was
> > incorporated by midonet-cluster (
> > https://github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster
> ).
> [https://avatars2.githubusercontent.com/u/9136532?v=3=400]<https://
> github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster>
>
> midonet/midonet<https://github.com/midonet/midonet/
> tree/staging/v5.4/midonet-cluster>
> github.com
> midonet - MidoNet is an Open Source network virtualization system for
> Openstack clouds
>
>
>
> >
> >
> > So, if anyone wants to invest energy on this, it might be a good
> idea to
> > upgrade the dependency. Moreover, I start to question the
> compatibility of
> > the current client we are using, with the mido-net server side that
> might
> > be deployed by users. Will this partial integration that we have
> work?
>
>
> Just as important to ask: "Has it ever worked?"
> Do we know anyone who use, or have used, this integration?
>
> --
> Erik
>
>
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>


-- 
Rafael Weingärtner

Re: midonet-client and Guava dependency conflict

[Daan Hoogland]

Well, if Midokura is not willing to put in effort, ... Not sure what to put on 
the dots.

On 14/03/17 15:08, "Simon Weller" <swel...@ena.com> wrote:

We took a look at testing it in the lab back in early 2016  and Midokura 
told us that it was a bad idea, probably wouldn't work and we should just 
switch to openstack.


- Si


From: Erik Weber <terbol...@gmail.com>
Sent: Tuesday, March 14, 2017 3:28 AM
To: dev
    Subject: Re: midonet-client and Guava dependency conflict

On Mon, Mar 13, 2017 at 7:45 PM, Rafael Weingärtner
<rafaelweingart...@gmail.com> wrote:
> I got a reply from Midonet community; they said that midonet-client was
> incorporated by midonet-cluster (
> https://github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster).

[https://avatars2.githubusercontent.com/u/9136532?v=3=400]<https://github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster>


midonet/midonet<https://github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster>
github.com
midonet - MidoNet is an Open Source network virtualization system for 
Openstack clouds



>
>
> So, if anyone wants to invest energy on this, it might be a good idea to
> upgrade the dependency. Moreover, I start to question the compatibility of
> the current client we are using, with the mido-net server side that might
> be deployed by users. Will this partial integration that we have work?


Just as important to ask: "Has it ever worked?"
Do we know anyone who use, or have used, this integration?

--
Erik



daan.hoogl...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: midonet-client and Guava dependency conflict

[Rafael Weingärtner]

Hmm, it seems that there are people who would like to use it in ACS.
However, by Simon`s email, the vendor does not seem to care much.

I am inclined to adopt one of Daan`s email previously:

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


Having said this, what do you guys think about removing this plugin from
ACS? Then, we remove from our documentation the “MidoNet support”.
Nowadays, I think we may bring expectation for people that may want to use
it, and at the end of the day, ACS will not deliver it.

Despite some people showing interest, this plugin does not work unless
someone puts quite some effort into it.

On Tue, Mar 14, 2017 at 10:08 AM, Simon Weller <swel...@ena.com> wrote:

> We took a look at testing it in the lab back in early 2016  and Midokura
> told us that it was a bad idea, probably wouldn't work and we should just
> switch to openstack.
>
>
> - Si
>
> 
> From: Erik Weber <terbol...@gmail.com>
> Sent: Tuesday, March 14, 2017 3:28 AM
> To: dev
> Subject: Re: midonet-client and Guava dependency conflict
>
> On Mon, Mar 13, 2017 at 7:45 PM, Rafael Weingärtner
> <rafaelweingart...@gmail.com> wrote:
> > I got a reply from Midonet community; they said that midonet-client was
> > incorporated by midonet-cluster (
> > https://github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster).
> [https://avatars2.githubusercontent.com/u/9136532?v=3=400]<https://
> github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster>
>
> midonet/midonet<https://github.com/midonet/midonet/
> tree/staging/v5.4/midonet-cluster>
> github.com
> midonet - MidoNet is an Open Source network virtualization system for
> Openstack clouds
>
>
>
> >
> >
> > So, if anyone wants to invest energy on this, it might be a good idea to
> > upgrade the dependency. Moreover, I start to question the compatibility
> of
> > the current client we are using, with the mido-net server side that might
> > be deployed by users. Will this partial integration that we have work?
>
>
> Just as important to ask: "Has it ever worked?"
> Do we know anyone who use, or have used, this integration?
>
> --
> Erik
>



-- 
Rafael Weingärtner

Re: midonet-client and Guava dependency conflict

[Simon Weller]

We took a look at testing it in the lab back in early 2016  and Midokura told 
us that it was a bad idea, probably wouldn't work and we should just switch to 
openstack.


- Si


From: Erik Weber <terbol...@gmail.com>
Sent: Tuesday, March 14, 2017 3:28 AM
To: dev
Subject: Re: midonet-client and Guava dependency conflict

On Mon, Mar 13, 2017 at 7:45 PM, Rafael Weingärtner
<rafaelweingart...@gmail.com> wrote:
> I got a reply from Midonet community; they said that midonet-client was
> incorporated by midonet-cluster (
> https://github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster).
[https://avatars2.githubusercontent.com/u/9136532?v=3=400]<https://github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster>

midonet/midonet<https://github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster>
github.com
midonet - MidoNet is an Open Source network virtualization system for Openstack 
clouds



>
>
> So, if anyone wants to invest energy on this, it might be a good idea to
> upgrade the dependency. Moreover, I start to question the compatibility of
> the current client we are using, with the mido-net server side that might
> be deployed by users. Will this partial integration that we have work?


Just as important to ask: "Has it ever worked?"
Do we know anyone who use, or have used, this integration?

--
Erik

Re: midonet-client and Guava dependency conflict

[Erik Weber]

On Mon, Mar 13, 2017 at 7:45 PM, Rafael Weingärtner
 wrote:
> I got a reply from Midonet community; they said that midonet-client was
> incorporated by midonet-cluster (
> https://github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster).
>
>
> So, if anyone wants to invest energy on this, it might be a good idea to
> upgrade the dependency. Moreover, I start to question the compatibility of
> the current client we are using, with the mido-net server side that might
> be deployed by users. Will this partial integration that we have work?


Just as important to ask: "Has it ever worked?"
Do we know anyone who use, or have used, this integration?

-- 
Erik

Re: midonet-client and Guava dependency conflict

[Daan Hoogland]

It has ended in we are stuck with a to old gson implementation and Wido build a 
call based on a newer one.

On 10/03/17 02:01, "Will Stevens" <williamstev...@gmail.com> wrote:

I will review. Thanks for digging that up. Haha. You know every issue now
because of your cleanup. :)

On Mar 9, 2017 7:51 PM, "Rafael Weingärtner" <rafaelweingart...@gmail.com>
wrote:

> https://issues.apache.org/jira/browse/CLOUDSTACK-8677
>
> On Thu, Mar 9, 2017 at 6:48 PM, Will Stevens <williamstev...@gmail.com>
> wrote:
>
> > I don't remember that conversation, but I will try to track it down.
> Thx...
> >
> > On Mar 9, 2017 6:39 PM, "Rafael Weingärtner" <
> rafaelweingart...@gmail.com>
> > wrote:
> >
> > > I recall a thread discussing some call home functionalities a long 
time
> > > ago; so, we could get some information about ACS usage. Does anyone
> know
> > > how that thread ended?
> > >
> > > The use o ACS plugin could be something trackable by a call home
> feature.
> > >
> > > On Thu, Mar 9, 2017 at 5:55 PM, Will Stevens <wstev...@cloudops.com>
> > > wrote:
> > >
> > > > 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?
> > > > > > >> >
> > > > > > >> >
> > 

Re: midonet-client and Guava dependency conflict

[Rafael Weingärtner]

I got a reply from Midonet community; they said that midonet-client was
incorporated by midonet-cluster (
https://github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster).


So, if anyone wants to invest energy on this, it might be a good idea to
upgrade the dependency. Moreover, I start to question the compatibility of
the current client we are using, with the mido-net server side that might
be deployed by users. Will this partial integration that we have work?

On Sat, Mar 11, 2017 at 2:49 AM, Paul Angus <paul.an...@shapeblue.com>
wrote:

> Jeff,
>
> To confirm what Rohit said, I spoke with Midokura a couple of years ago,
> they did some basics, then were looking for a customer to finish/polish the
> implementation with.
>
> AFAIK that never happened, as customers wanted to see it working FIRST
> before signing up.
>
> Kind regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>
> -Original Message-
> From: Jeff Hair [mailto:j...@greenqloud.com]
> Sent: 10 March 2017 13:45
> To: dev@cloudstack.apache.org
> Subject: Re: midonet-client and Guava dependency conflict
>
> 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
> j...@greenqloud.com
> www.greenqloud.com
>
> On Fri, Mar 10, 2017 at 1:34 PM, Rafael Weingärtner <
> rafaelweingart...@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 <j...@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
> > > 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

RE: midonet-client and Guava dependency conflict

[Paul Angus]

Jeff,

To confirm what Rohit said, I spoke with Midokura a couple of years ago, they 
did some basics, then were looking for a customer to finish/polish the 
implementation with.

AFAIK that never happened, as customers wanted to see it working FIRST before 
signing up.

Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Jeff Hair [mailto:j...@greenqloud.com] 
Sent: 10 March 2017 13:45
To: dev@cloudstack.apache.org
Subject: Re: midonet-client and Guava dependency conflict

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
j...@greenqloud.com
www.greenqloud.com

On Fri, Mar 10, 2017 at 1:34 PM, Rafael Weingärtner < 
rafaelweingart...@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 <j...@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
> > 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=400] > > :// 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 alphabet

Re: midonet-client and Guava dependency conflict

[Rafael Weingärtner]

r*
> > > >> > 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=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
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Rafael Weingärtner
> > > >>
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>



-- 
Rafael Weingärtner

Re: midonet-client and Guava dependency conflict

[Jeff Hair]

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
j...@greenqloud.com
www.greenqloud.com

On Fri, Mar 10, 2017 at 2:38 PM, Rafael Weingärtner <
rafaelweingart...@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 <j...@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
> > j...@greenqloud.com
> > www.greenqloud.com
> >
> > On Fri, Mar 10, 2017 at 1:44 PM, Jeff Hair <j...@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
> > > j...@greenqloud.com
> > > www.greenqloud.com
> > >
> > > On Fri, Mar 10, 2017 at 1:34 PM, Rafael Weingärtner <
> > > rafaelweingart...@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 <j...@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
> > >> > 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.
> > >> > >
> > >> > >
> > 

Re: midonet-client and Guava dependency conflict

[Rafael Weingärtner]

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 <j...@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
> j...@greenqloud.com
> www.greenqloud.com
>
> On Fri, Mar 10, 2017 at 1:44 PM, Jeff Hair <j...@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
> > j...@greenqloud.com
> > www.greenqloud.com
> >
> > On Fri, Mar 10, 2017 at 1:34 PM, Rafael Weingärtner <
> > rafaelweingart...@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 <j...@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
> >> > 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
> >> > >
> >> > >
> >> > > 
> >&g

Re: midonet-client and Guava dependency conflict

[Jeff Hair]

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
j...@greenqloud.com
www.greenqloud.com

On Fri, Mar 10, 2017 at 1:44 PM, Jeff Hair <j...@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
> j...@greenqloud.com
> www.greenqloud.com
>
> On Fri, Mar 10, 2017 at 1:34 PM, Rafael Weingärtner <
> rafaelweingart...@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 <j...@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
>> > 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:/

Re: midonet-client and Guava dependency conflict

[Jeff Hair]

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
j...@greenqloud.com
www.greenqloud.com

On Fri, Mar 10, 2017 at 1:34 PM, Rafael Weingärtner <
rafaelweingart...@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 <j...@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
> > 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=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

Re: midonet-client and Guava dependency conflict

[Rafael Weingärtner]

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 <j...@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
> 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=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
> > >
> >
>



-- 
Rafael Weingärtner

Re: midonet-client and Guava dependency conflict

[Jeff Hair]

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

Re: midonet-client and Guava dependency conflict

[Rohit Yadav]

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

Re: midonet-client and Guava dependency conflict

[Syed Ahmed]

We can look at the gut history and try to contact the guy who wrote the
plugin to get more info about who's using it
On Thu, Mar 9, 2017 at 20:01 Will Stevens <williamstev...@gmail.com> wrote:

> I will review. Thanks for digging that up. Haha. You know every issue now
> because of your cleanup. :)
>
> On Mar 9, 2017 7:51 PM, "Rafael Weingärtner" <rafaelweingart...@gmail.com>
> wrote:
>
> > https://issues.apache.org/jira/browse/CLOUDSTACK-8677
> >
> > On Thu, Mar 9, 2017 at 6:48 PM, Will Stevens <williamstev...@gmail.com>
> > wrote:
> >
> > > I don't remember that conversation, but I will try to track it down.
> > Thx...
> > >
> > > On Mar 9, 2017 6:39 PM, "Rafael Weingärtner" <
> > rafaelweingart...@gmail.com>
> > > wrote:
> > >
> > > > I recall a thread discussing some call home functionalities a long
> time
> > > > ago; so, we could get some information about ACS usage. Does anyone
> > know
> > > > how that thread ended?
> > > >
> > > > The use o ACS plugin could be something trackable by a call home
> > feature.
> > > >
> > > > On Thu, Mar 9, 2017 at 5:55 PM, Will Stevens <wstev...@cloudops.com>
> > > > wrote:
> > > >
> > > > > 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

Re: midonet-client and Guava dependency conflict

[Syed Ahmed]

*git history

Sorry got autocorrected
On Thu, Mar 9, 2017 at 20:54 Syed Ahmed <sah...@cloudops.com> wrote:

> We can look at the gut history and try to contact the guy who wrote the
> plugin to get more info about who's using it
> On Thu, Mar 9, 2017 at 20:01 Will Stevens <williamstev...@gmail.com>
> wrote:
>
> I will review. Thanks for digging that up. Haha. You know every issue now
> because of your cleanup. :)
>
> On Mar 9, 2017 7:51 PM, "Rafael Weingärtner" <rafaelweingart...@gmail.com>
> wrote:
>
> > https://issues.apache.org/jira/browse/CLOUDSTACK-8677
> >
> > On Thu, Mar 9, 2017 at 6:48 PM, Will Stevens <williamstev...@gmail.com>
> > wrote:
> >
> > > I don't remember that conversation, but I will try to track it down.
> > Thx...
> > >
> > > On Mar 9, 2017 6:39 PM, "Rafael Weingärtner" <
> > rafaelweingart...@gmail.com>
> > > wrote:
> > >
> > > > I recall a thread discussing some call home functionalities a long
> time
> > > > ago; so, we could get some information about ACS usage. Does anyone
> > know
> > > > how that thread ended?
> > > >
> > > > The use o ACS plugin could be something trackable by a call home
> > feature.
> > > >
> > > > On Thu, Mar 9, 2017 at 5:55 PM, Will Stevens <wstev...@cloudops.com>
> > > > wrote:
> > > >
> > > > > 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
>

Re: midonet-client and Guava dependency conflict

[Will Stevens]

I will review. Thanks for digging that up. Haha. You know every issue now
because of your cleanup. :)

On Mar 9, 2017 7:51 PM, "Rafael Weingärtner" <rafaelweingart...@gmail.com>
wrote:

> https://issues.apache.org/jira/browse/CLOUDSTACK-8677
>
> On Thu, Mar 9, 2017 at 6:48 PM, Will Stevens <williamstev...@gmail.com>
> wrote:
>
> > I don't remember that conversation, but I will try to track it down.
> Thx...
> >
> > On Mar 9, 2017 6:39 PM, "Rafael Weingärtner" <
> rafaelweingart...@gmail.com>
> > wrote:
> >
> > > I recall a thread discussing some call home functionalities a long time
> > > ago; so, we could get some information about ACS usage. Does anyone
> know
> > > how that thread ended?
> > >
> > > The use o ACS plugin could be something trackable by a call home
> feature.
> > >
> > > On Thu, Mar 9, 2017 at 5:55 PM, Will Stevens <wstev...@cloudops.com>
> > > wrote:
> > >
> > > > 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
> > > > > > >> >
> > > > >

Re: midonet-client and Guava dependency conflict

[Rafael Weingärtner]

https://issues.apache.org/jira/browse/CLOUDSTACK-8677

On Thu, Mar 9, 2017 at 6:48 PM, Will Stevens <williamstev...@gmail.com>
wrote:

> I don't remember that conversation, but I will try to track it down. Thx...
>
> On Mar 9, 2017 6:39 PM, "Rafael Weingärtner" <rafaelweingart...@gmail.com>
> wrote:
>
> > I recall a thread discussing some call home functionalities a long time
> > ago; so, we could get some information about ACS usage. Does anyone know
> > how that thread ended?
> >
> > The use o ACS plugin could be something trackable by a call home feature.
> >
> > On Thu, Mar 9, 2017 at 5:55 PM, Will Stevens <wstev...@cloudops.com>
> > wrote:
> >
> > > 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.
> > > > > >> >
> > > > &

Re: midonet-client and Guava dependency conflict

[Will Stevens]

I don't remember that conversation, but I will try to track it down. Thx...

On Mar 9, 2017 6:39 PM, "Rafael Weingärtner" <rafaelweingart...@gmail.com>
wrote:

> I recall a thread discussing some call home functionalities a long time
> ago; so, we could get some information about ACS usage. Does anyone know
> how that thread ended?
>
> The use o ACS plugin could be something trackable by a call home feature.
>
> On Thu, Mar 9, 2017 at 5:55 PM, Will Stevens <wstev...@cloudops.com>
> wrote:
>
> > 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=400
> > > ]<https://
> > > > >> github.com/openwide-java/tomcat-classloader-ordered>
> > > > >> >
> > > > >> > GitHub - openwide-java/tomcat-classloader-ordered: A ...<
> > > > >> https://github.com/openwide-java/tomcat-classloader-ordered>
> > > &

Re: midonet-client and Guava dependency conflict

[Rafael Weingärtner]

I recall a thread discussing some call home functionalities a long time
ago; so, we could get some information about ACS usage. Does anyone know
how that thread ended?

The use o ACS plugin could be something trackable by a call home feature.

On Thu, Mar 9, 2017 at 5:55 PM, Will Stevens <wstev...@cloudops.com> wrote:

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

Re: midonet-client and Guava dependency conflict

[Will Stevens]

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

Re: midonet-client and Guava dependency conflict

[Rafael Weingärtner]

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

Re: midonet-client and Guava dependency conflict

[Daan Hoogland]

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

Re: midonet-client and Guava dependency conflict

[Rafael Weingärtner]

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

Re: midonet-client and Guava dependency conflict

[Daan Hoogland]

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

Re: midonet-client and Guava dependency conflict

[Simon Weller]

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

Re: midonet-client and Guava dependency conflict

[Jeff Hair]

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

midonet-client and Guava dependency conflict

[Jeff Hair]

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

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