Great, I'll push that to trunk, and if nobody's CI complains, ask Justin to include it in 0.24.
thanks for testing it. -K ----- Original Message ----- > From: "Bill Freeman" <ke1g...@gmail.com> > To: "users" <users@qpid.apache.org> > Sent: Friday, July 26, 2013 11:07:09 AM > Subject: Re: Telling v1 events from v2 events using qmf.console python QMF > library > > Ken, > > It works for me. > > Bill > > > On Thu, Jul 25, 2013 at 6:43 PM, Ken Giusti <kgiu...@redhat.com> wrote: > > > Hi Bill, > > > > Care to try out a patch for me? > > > > https://issues.apache.org/jira/browse/QPID-5019 > > > > If this works, I'll try to get Justin to approve it for 0.24, that way it > > will be in the next release (as well as trunk). > > > > ----- Original Message ----- > > > From: "Bill Freeman" <ke1g...@gmail.com> > > > To: "users" <users@qpid.apache.org> > > > Sent: Thursday, July 25, 2013 4:28:50 PM > > > Subject: Re: Telling v1 events from v2 events using qmf.console python > > QMF library > > > > > > Ken, > > > > > > Thanks. > > > > > > That works for me. Probably naming it "isV2" to match the one in > > ObjectId > > > instances would be wise. > > > > > > If I know that it's coming I can make my patch the same way, knowing that > > > when I get around to accepting a new enough released version to obviate > > the > > > need for my patched one, my code won't have to change in this area. > > > > > > Bill > > > > > > > > > On Thu, Jul 25, 2013 at 3:58 PM, Ken Giusti <kgiu...@redhat.com> wrote: > > > > > > > Hi Bill, > > > > > > > > I don't think there is a way to distinguish the two - when they're > > passed > > > > to the console callback, they'll be identical. We need to fix that. > > > > > > > > Adding a isV2 attribute to the event sounds like a good approach. Let > > me > > > > know, I'd like to patch that into 0.24 and trunk so it will be > > available in > > > > future releases. > > > > > > > > -K > > > > > > > > > > > > ----- Original Message ----- > > > > > From: "Bill Freeman" <ke1g...@gmail.com> > > > > > To: "users" <users@qpid.apache.org> > > > > > Sent: Thursday, July 25, 2013 12:24:34 PM > > > > > Subject: Telling v1 events from v2 events using qmf.console python > > QMF > > > > library > > > > > > > > > > I've started working on detecting when a queue has been deleted. One > > > > > possibility is to track the queueDelete QMF events. > > > > > > > > > > I noticed that I get 2 of each event (using an older qmf.console > > that has > > > > > been patched as recently discussed to allow v2 to happen at all). > > Using > > > > > pdb to crawl up the stack, I confirmed that one is a v1 event, and > > the > > > > > other is a v2 event. > > > > > > > > > > I'd like to discard one, preferably the v1, so that I know my code > > will > > > > > still work in a future when the brokers aren't sending v1 events > > anymore. > > > > > But at the point that the Console.event callback is called, I don't > > see > > > > how > > > > > to distinguish the two. For objectProps and objectStatis I can get > > an > > > > > ObjectID instance and use its isV2 attribute, but I don't believe > > that's > > > > > available for Event instances. > > > > > > > > > > It would be easy enough for me to also patch the Event constructor > > (it > > > > > knows because of the presence or absence of a dict as the v2Map > > > > constructor > > > > > argument) to mark the Event object suitably. (I'm thinking of > > adding an > > > > > isV1 boolean that I'll check with getattr(event, 'isV1', False) so > > that > > > > the > > > > > code will do the right thing with a future where only v2 events are > > > > > delivered by code that knows nothing about the flag.) > > > > > > > > > > But am I missing an existing easier solution? > > > > > > > > > > Bill > > > > > > > > > > > > > -- > > > > -K > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > > > > > > > > > > > -- > > -K > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > > For additional commands, e-mail: users-h...@qpid.apache.org > > > > > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
