You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Rafael Schloming <rh...@alum.mit.edu> on 2014/07/10 18:41:05 UTC
landing events branch
Hi Everyone,
I wanted to give people a quick heads up. I would like to land the events
branch soon. If you don't use the events API then this probably won't
impact you, however if you do then you may experience some compilation
failures. This is because of the following changes:
The PN_{CONNECTION,SESSION,LINK}_LOCAL_STATE events have been decomposed
into two distinct events:
PN_{CONNECTION,SESSION,LINK}_OPEN and PN_{CONNECTION,SESSION,LINK}_CLOSE
Similarly, PN_{CONNECTION,SESSION,LINK}_REMOTE_STATE has been decomposed
into:
PN_{CONNECTION,SESSION,LINK}_REMOTE_OPEN and
PN_{CONNECTION,SESSION,LINK}_REMOTE_CLOSE
To fix your code all you need to do is adjust your switch statements to
match on the new names, e.g. something like this:
...
case PN_CONNECTION_REMOTE_STATE:
...
Would become something like this:
...
case PN_CONNECTION_REMOTE_OPEN: // fall through
case PN_CONNECTION_REMOTE_CLOSE:
...
Please give me a shout if this will cause a problem for you, otherwise I
will land the branch in a day or two.
--Rafael
Re: landing events branch
Posted by Ted Ross <tr...@redhat.com>.
On 07/23/2014 05:29 AM, Gordon Sim wrote:
> On 07/22/2014 09:28 PM, Ted Ross wrote:
>> Another heads-up... I've updated dispatch-router to use the newly landed
>> events in Proton. If you are building dispatch from source, you will
>> need the latest Proton trunk.
>
> What is the plan for the next release of dispatch router? I assume that
> this ties it to proton 0.8, whenever that is to be released?
Unless we use a way to detect at compile-time which proton we're using,
it will depend on 0.8.
The roadmap calls for a 0.3 in July
(https://cwiki.apache.org/confluence/display/qpid/Dispatch+Roadmap).
Realistically, I think we will slip a little beyond July.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: landing events branch
Posted by Gordon Sim <gs...@redhat.com>.
On 07/22/2014 09:28 PM, Ted Ross wrote:
> Another heads-up... I've updated dispatch-router to use the newly landed
> events in Proton. If you are building dispatch from source, you will
> need the latest Proton trunk.
What is the plan for the next release of dispatch router? I assume that
this ties it to proton 0.8, whenever that is to be released?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: landing events branch
Posted by Ted Ross <tr...@redhat.com>.
Another heads-up... I've updated dispatch-router to use the newly landed
events in Proton. If you are building dispatch from source, you will
need the latest Proton trunk.
-Ted
On 07/10/2014 12:41 PM, Rafael Schloming wrote:
> Hi Everyone,
>
> I wanted to give people a quick heads up. I would like to land the events
> branch soon. If you don't use the events API then this probably won't
> impact you, however if you do then you may experience some compilation
> failures. This is because of the following changes:
>
> The PN_{CONNECTION,SESSION,LINK}_LOCAL_STATE events have been decomposed
> into two distinct events:
>
> PN_{CONNECTION,SESSION,LINK}_OPEN and PN_{CONNECTION,SESSION,LINK}_CLOSE
>
> Similarly, PN_{CONNECTION,SESSION,LINK}_REMOTE_STATE has been decomposed
> into:
>
> PN_{CONNECTION,SESSION,LINK}_REMOTE_OPEN and
> PN_{CONNECTION,SESSION,LINK}_REMOTE_CLOSE
>
> To fix your code all you need to do is adjust your switch statements to
> match on the new names, e.g. something like this:
>
> ...
> case PN_CONNECTION_REMOTE_STATE:
> ...
>
> Would become something like this:
>
> ...
> case PN_CONNECTION_REMOTE_OPEN: // fall through
> case PN_CONNECTION_REMOTE_CLOSE:
> ...
>
> Please give me a shout if this will cause a problem for you, otherwise I
> will land the branch in a day or two.
>
> --Rafael
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: landing events branch
Posted by Ted Ross <tr...@redhat.com>.
Another heads-up... I've updated dispatch-router to use the newly landed
events in Proton. If you are building dispatch from source, you will
need the latest Proton trunk.
-Ted
On 07/10/2014 12:41 PM, Rafael Schloming wrote:
> Hi Everyone,
>
> I wanted to give people a quick heads up. I would like to land the events
> branch soon. If you don't use the events API then this probably won't
> impact you, however if you do then you may experience some compilation
> failures. This is because of the following changes:
>
> The PN_{CONNECTION,SESSION,LINK}_LOCAL_STATE events have been decomposed
> into two distinct events:
>
> PN_{CONNECTION,SESSION,LINK}_OPEN and PN_{CONNECTION,SESSION,LINK}_CLOSE
>
> Similarly, PN_{CONNECTION,SESSION,LINK}_REMOTE_STATE has been decomposed
> into:
>
> PN_{CONNECTION,SESSION,LINK}_REMOTE_OPEN and
> PN_{CONNECTION,SESSION,LINK}_REMOTE_CLOSE
>
> To fix your code all you need to do is adjust your switch statements to
> match on the new names, e.g. something like this:
>
> ...
> case PN_CONNECTION_REMOTE_STATE:
> ...
>
> Would become something like this:
>
> ...
> case PN_CONNECTION_REMOTE_OPEN: // fall through
> case PN_CONNECTION_REMOTE_CLOSE:
> ...
>
> Please give me a shout if this will cause a problem for you, otherwise I
> will land the branch in a day or two.
>
> --Rafael
>
Re: landing events branch
Posted by Robbie Gemmell <ro...@gmail.com>.
I wasn't able to run the tests via cmake or maven after updating and doing
a clean build, getting complaint: AttributeError: type object
'org.apache.qpid.proton.engine.Event$Category' has no attribute 'PROTOCOL'
As I saw that the CI job completed ok and knew that this was an area being
changed in the latest comits, I figured that there must be some erroneous
stale files left in my checkout since the main difference is Jenkins being
set to clear away such files before updating to the latest revision. A
little git-clean usage showed that to be the case, with various .pyc and
py.class files lying around in the tests dir particularly.
To do a git-clean dry run and see the files/dirs that would be removed:
git clean -n -d -x -e "*.classpath" -e "*.project" -e "*.settings" .
To actually remove them:
git clean -f -d -x -e "*.classpath" -e "*.project" -e "*.settings" .
The -e options are just making it ignore some IDE related files/dirs from
being nuked after the -x makes it consider things it normally ignores, so
update or remove the -e flags according to your own needs.
After cleanup, running the tests worked fine. I can only presume this
happened due to leaving stale files around after playing around on branches
previously. Perhaps the tests module needs updated to clear away such files
when doing a clean build.
Robbie
On 17 July 2014 21:07, Rafael Schloming <rh...@alum.mit.edu> wrote:
> FYI, the events branch is now landed on trunk. Please let me know if you
> run into any issues.
>
> --Rafael
>
>
> On Thu, Jul 10, 2014 at 2:10 PM, Božo Dragojevič <bo...@digiverse.si>
> wrote:
>
> > On Jul 10, 2014 6:41 PM, "Rafael Schloming" <rh...@alum.mit.edu> wrote:
> > >
> > > Hi Everyone,
> > >
> > > I wanted to give people a quick heads up. I would like to land the
> events
> > > branch soon. If you don't use the events API then this probably won't
> > > impact you, however if you do then you may experience some compilation
> > > failures. This is because of the following changes:
> > >
> > > The PN_{CONNECTION,SESSION,LINK}_LOCAL_STATE events have been
> decomposed
> > > into two distinct events:
> > >
> > > PN_{CONNECTION,SESSION,LINK}_OPEN and
> > PN_{CONNECTION,SESSION,LINK}_CLOSE
> > >
> > > Similarly, PN_{CONNECTION,SESSION,LINK}_REMOTE_STATE has been
> decomposed
> > > into:
> > >
> > > PN_{CONNECTION,SESSION,LINK}_REMOTE_OPEN and
> > > PN_{CONNECTION,SESSION,LINK}_REMOTE_CLOSE
> > >
> > > To fix your code all you need to do is adjust your switch statements to
> > > match on the new names, e.g. something like this:
> > >
> > > ...
> > > case PN_CONNECTION_REMOTE_STATE:
> > > ...
> > >
> > > Would become something like this:
> > >
> > > ...
> > > case PN_CONNECTION_REMOTE_OPEN: // fall through
> > > case PN_CONNECTION_REMOTE_CLOSE:
> > > ...
> > >
> > > Please give me a shout if this will cause a problem for you, otherwise
> I
> > > will land the branch in a day or two.
> > >
> >
> > When speed reading the new event api the other day, the change seemed
> > quite large, but such a mechanic change seems easy to adapt.
> >
> > Bozzo
> >
>
Re: landing events branch
Posted by Rafael Schloming <rh...@alum.mit.edu>.
FYI, the events branch is now landed on trunk. Please let me know if you
run into any issues.
--Rafael
On Thu, Jul 10, 2014 at 2:10 PM, Božo Dragojevič <bo...@digiverse.si> wrote:
> On Jul 10, 2014 6:41 PM, "Rafael Schloming" <rh...@alum.mit.edu> wrote:
> >
> > Hi Everyone,
> >
> > I wanted to give people a quick heads up. I would like to land the events
> > branch soon. If you don't use the events API then this probably won't
> > impact you, however if you do then you may experience some compilation
> > failures. This is because of the following changes:
> >
> > The PN_{CONNECTION,SESSION,LINK}_LOCAL_STATE events have been decomposed
> > into two distinct events:
> >
> > PN_{CONNECTION,SESSION,LINK}_OPEN and
> PN_{CONNECTION,SESSION,LINK}_CLOSE
> >
> > Similarly, PN_{CONNECTION,SESSION,LINK}_REMOTE_STATE has been decomposed
> > into:
> >
> > PN_{CONNECTION,SESSION,LINK}_REMOTE_OPEN and
> > PN_{CONNECTION,SESSION,LINK}_REMOTE_CLOSE
> >
> > To fix your code all you need to do is adjust your switch statements to
> > match on the new names, e.g. something like this:
> >
> > ...
> > case PN_CONNECTION_REMOTE_STATE:
> > ...
> >
> > Would become something like this:
> >
> > ...
> > case PN_CONNECTION_REMOTE_OPEN: // fall through
> > case PN_CONNECTION_REMOTE_CLOSE:
> > ...
> >
> > Please give me a shout if this will cause a problem for you, otherwise I
> > will land the branch in a day or two.
> >
>
> When speed reading the new event api the other day, the change seemed
> quite large, but such a mechanic change seems easy to adapt.
>
> Bozzo
>
Re: landing events branch
Posted by Božo Dragojevič <bo...@digiverse.si>.
On Jul 10, 2014 6:41 PM, "Rafael Schloming" <rh...@alum.mit.edu> wrote:
>
> Hi Everyone,
>
> I wanted to give people a quick heads up. I would like to land the events
> branch soon. If you don't use the events API then this probably won't
> impact you, however if you do then you may experience some compilation
> failures. This is because of the following changes:
>
> The PN_{CONNECTION,SESSION,LINK}_LOCAL_STATE events have been decomposed
> into two distinct events:
>
> PN_{CONNECTION,SESSION,LINK}_OPEN and PN_{CONNECTION,SESSION,LINK}_CLOSE
>
> Similarly, PN_{CONNECTION,SESSION,LINK}_REMOTE_STATE has been decomposed
> into:
>
> PN_{CONNECTION,SESSION,LINK}_REMOTE_OPEN and
> PN_{CONNECTION,SESSION,LINK}_REMOTE_CLOSE
>
> To fix your code all you need to do is adjust your switch statements to
> match on the new names, e.g. something like this:
>
> ...
> case PN_CONNECTION_REMOTE_STATE:
> ...
>
> Would become something like this:
>
> ...
> case PN_CONNECTION_REMOTE_OPEN: // fall through
> case PN_CONNECTION_REMOTE_CLOSE:
> ...
>
> Please give me a shout if this will cause a problem for you, otherwise I
> will land the branch in a day or two.
>
When speed reading the new event api the other day, the change seemed
quite large, but such a mechanic change seems easy to adapt.
Bozzo