Re: [jira] [Created] (PROTON-269) Connect Redirect parsing incorrectly uses position in map rather than value of key
The reason for the failure is pretty obvious, I forgot to update the jython
shim. What I'm a bit more confused about is why 'make test' didn't catch
this. I believe I have all the necessary prerequisites to exercise the
jython shim via the JNI tests on my system, however that doesn't appear to
be happening.
--Rafael
On Thu, Mar 14, 2013 at 5:36 AM, Phil Harvey p...@philharveyonline.comwrote:
I see that the proton-jni Jenkins jobs is now failing, presumably because
of the commit in revision 1456100 for this Jira.
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/50/
Is anyone planning to look into this?
Thanks
Phil
On 10 March 2013 15:59, Rob Godfrey (JIRA) j...@apache.org wrote:
Rob Godfrey created PROTON-269:
--
Summary: Connect Redirect parsing incorrectly uses position
in map rather than value of key
Key: PROTON-269
URL: https://issues.apache.org/jira/browse/PROTON-269
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Rob Godfrey
The connection error redirect is defined to carry an info map of the
following form:
The container is no longer available on the current connection. The peer
should attempt reconnection to the container using the details provided
in
the info map.
hostname: the hostname of the container. This is the value that should
be supplied in the hostname field of the open frame, and during the SASL
and TLS negotiation (if used).
network-host: the DNS hostname or IP address of the machine hosting the
container.
port: the port number on the machine hosting the container.
However proton-c completely ignores the values of the keys in the info
map
and instead assumes that network host will be the value in the second
key-value pair, and port will be the value in the thirs key-value pair;
e.g.:
const char *pn_condition_redirect_host(pn_condition_t *condition)
{
pn_data_t *data = pn_condition_info(condition);
pn_data_rewind(data);
pn_data_next(data);
pn_data_enter(data);
pn_data_next(data);
pn_data_next(data);
pn_data_next(data);
pn_data_next(data);
pn_bytes_t host = pn_data_get_bytes(data);
pn_data_rewind(data);
return host.start;
}
This is incorrect behaviour.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-271) proton-hawtdispatch transport not properly encoding PLAIN sasl user/password.
Hiram Chirino created PROTON-271: Summary: proton-hawtdispatch transport not properly encoding PLAIN sasl user/password. Key: PROTON-271 URL: https://issues.apache.org/jira/browse/PROTON-271 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.3 Reporter: Hiram Chirino Assignee: Hiram Chirino It fails to connect to RabbitMQ. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-271) proton-hawtdispatch transport not properly encoding PLAIN sasl user/password.
[ https://issues.apache.org/jira/browse/PROTON-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated PROTON-271: - Attachment: PROTON-271.patch Attaching patch that fixes the issue. proton-hawtdispatch transport not properly encoding PLAIN sasl user/password. - Key: PROTON-271 URL: https://issues.apache.org/jira/browse/PROTON-271 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: 0.3 Reporter: Hiram Chirino Assignee: Hiram Chirino Attachments: PROTON-271.patch It fails to connect to RabbitMQ. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Why 2 space indentations??
On Thu, Mar 14, 2013 at 10:50 AM, Ken Giusti kgiu...@redhat.com wrote: - Original Message - From: Rafael Schloming r...@alum.mit.edu To: proton@qpid.apache.org Sent: Thursday, March 14, 2013 10:07:02 AM Subject: Re: Why 2 space indentations?? On Thu, Mar 14, 2013 at 9:18 AM, Ken Giusti kgiu...@redhat.com wrote: Not to fire off a religious flame-war here - but this has stuck in my craw for awhile: Why is the proton C and Python code using 2 space indent? Two space indent does not conform with the existing QPID coding guidelines established for C++ nor Java: https://cwiki.apache.org/qpid/java-coding-standards.html https://cwiki.apache.org/qpid/cppstyleguide.html even python code should not be using 2 space indents, as God and Guido intended: http://www.python.org/dev/peps/pep-0008/#indentation Heck - the proton-j Java code uses 4 spaces! We're not even self-consistent! Sorry to bring this up - there's plenty of real work that needs to be done for proton. But I'm OLD, and my eyes ain't what they used to be. Working with 2 space indents isn't fun. In the case of python, it's damn painful. Going forward, can we please use 4 space indents? And, over time, convert the existing codebase? I'm not happy with the idea of going back and converting old files, at least not for any of those that I maintain. When I end up debugging code that I maintain that has other people's commits sprinkled in, I often go back and isolate them in order to to understand their effect on the original code, and this gets very difficult when you have sweeping whitespace changes. HiRafi,that'sfunnybecauseI'mhavingahardtimemaintainingthecode,too.Ifindmyselfconstantlyhavingtonavigatethesourcecodetryingtolineupindentationblocks. Funny what a big difference a little whitespace makes in readability. FWIW, I don't actually interpret pep-8 quite as strongly as you do. It seems more emphatic about not using tabs or 8 spaces, and it is all prefixed with these very wise words[1]. In particular note the section on consistency within files and projects being more important that adherence to pep-8. [1] http://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds I point out PEP 8 because the QPID project only states programming guidelines for C++ and Java code. Both of which, as I've previously pointed out, explicitly recommend 4 space indent. In lieu of an explicit recommendation by QPID for Python, I defer to the language's recommendation. Foolish consistency? Perhaps. Better readability. Definitely. Given the above section, I took the liberty of counting our de-facto standard for both qpid and proton: Qpid has 56.4KLOC in 188 files using 2 space indent and 44.8KLOC in 120 files using something other than 2 space indent For a total of 308 files? Hmmm... from the topmost qpid dir, after git clean -fdx, I get quite a different number of source files: find ./java ./cpp \( -name *.cpp -o -name *.h -o -name *.java \) | wc 33953395 238808 And how did you distinguish the indent? I only counted python files. I don't think the java or cpp guidelines are at all relevant to python code. --Rafael
Re: Jira numbers in commit messages
If I see NO-JIRA then I usually infer that the author considered whether a Jira was required and decided not. Without this marker, I can't distinguish between deliberate and accidental omission of the Jira number. On 14 March 2013 14:47, Rafael Schloming r...@alum.mit.edu wrote: To be honest, I've never really understood the point of the NO-JIRA thing. What's the technical difference between NO-JIRA: blah and simply omitting the PROTON-xxx? I can't see that it would significantly improve grepability since either way you need to run a regex over the whole log string for anything that matches PROTON-[0-9]+. --Rafael On Thu, Mar 14, 2013 at 10:31 AM, Phil Harvey p...@philharveyonline.com wrote: I notice a fair smattering of recent Proton commits without Jira numbers in them. As far as I'm aware, all commits should either contain a Jira number in the format PROTON-xyz: or, for exceptionally simple changes, NO-JIRA:. Please shout if you disagree. Thanks Phil
Re: Yet Another communication improvement suggestion
I definitely agree we should make both the longer term roadmap and the things being actively worked on for the next release more visible. One frustration I've had with our communication tools has been with the wiki. I actually had quite a good experience at first. I was happy with how easy it was to author the Protocol Engines doc I wrote a little while back. Since then though I have noticed that it is very difficult to find something once you've authored it. There is no obvious way to navigate to the page when you go here: https://cwiki.apache.org/qpid/, the search box on the top doesn't seem to work well at all, and if you google proton protocol engines you actually get to the mailing list updates for the document but not the document itself. I think any process that somehow distills and summarizes the higher frequency activity from jira/lists/irc, would really need to solve and/or find a better means of publishing the info than we currently have with the wiki. I think we have a general gap in (good) tooling for low frequence/live updated material. Regarding the specific process you mention, I'd be happy to contribute to periodic status/activity updates. I would, however, prefer a more distributed process than funnelling through one person, i.e. put the updates into some kind of shared/concurrently editable thing, e.g. a wiki page or a google doc. --Rafael On Tue, Mar 12, 2013 at 1:22 PM, Phil Harvey p...@philharveyonline.comwrote: There is a lot of really exciting development being done on Proton at the moment. However, I often wish that I had better visibility of ongoing work, so that I could better complement the work others are doing. Currently, the ways I find out about this work are: - Jira updates - The mailing list - IRC There are two problems with this: (1) I only get a partial view of what's going on, and (2) stuff usually gets put on Jira and the mailing list too late, i.e. when it's already in progress or is actually finished. Also, we do have a roadmap on the wiki [1], but I don't think this is used by many people at the moment. Maybe my desire for more visibility and coordination could be viewed as rather command and control, and therefore not in the spirit of open source. I'd be interested to hear what others think about this. For the record, what I think we should introduce is: 1. A regular round-up email that gets sent to the list. Someone would be responsible for collating brief emails from developers describing what they're planning to work on, and would condense this into something useful to the general Proton community. I would be happy to perform this role. This round-up would necessarily be descriptive, not prescriptive. 2. We would commit to keeping the roadmap more up to date so that it becomes a useful resource for people wishing to work in a complementary way. I believe that most of the above points could apply to the Qpid project as a whole. But, to avoid trying to boil the ocean, I thought it would be worth testing these ideas in the narrower Proton domain first. Phil [1] https://cwiki.apache.org/confluence/display/qpid/AMQP+1.0+Roadmap
Re: Jira numbers in commit messages
Surely either way you need to read the actual log message to distinguish between correct and incorrect omission of the JIRA number. I would hate to think you'd let something like NO-JIRA: overhauled user facing API go by just because it was prefixed. ;-) --Rafael On Thu, Mar 14, 2013 at 11:38 AM, Phil Harvey p...@philharveyonline.comwrote: If I see NO-JIRA then I usually infer that the author considered whether a Jira was required and decided not. Without this marker, I can't distinguish between deliberate and accidental omission of the Jira number. On 14 March 2013 14:47, Rafael Schloming r...@alum.mit.edu wrote: To be honest, I've never really understood the point of the NO-JIRA thing. What's the technical difference between NO-JIRA: blah and simply omitting the PROTON-xxx? I can't see that it would significantly improve grepability since either way you need to run a regex over the whole log string for anything that matches PROTON-[0-9]+. --Rafael On Thu, Mar 14, 2013 at 10:31 AM, Phil Harvey p...@philharveyonline.com wrote: I notice a fair smattering of recent Proton commits without Jira numbers in them. As far as I'm aware, all commits should either contain a Jira number in the format PROTON-xyz: or, for exceptionally simple changes, NO-JIRA:. Please shout if you disagree. Thanks Phil
[jira] [Commented] (PROTON-270) Make artifactId for proton tests more descriptive
[ https://issues.apache.org/jira/browse/PROTON-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602393#comment-13602393 ] Robbie Gemmell commented on PROTON-270: --- I dont particularly mind the group id, as I think the artifact id is likely going to have to contain proton in order to differentiate the jar names from other projects (or parent projects), meaning either way works for the groupId. My only real interest in this was that at some point we should end up with naming being somewhat consistent between releases and between artifacts. Thus far it seems like almost every release of proton-j has had different artifact names than the last, which makes it slightly harder for users to track new releases and clutters up search results (try searching for qpid artifacts and you also get some old proton results, then search for proton and you get a mixture of current and once or twice defunct proton artifacts names). Make artifactId for proton tests more descriptive - Key: PROTON-270 URL: https://issues.apache.org/jira/browse/PROTON-270 Project: Qpid Proton Issue Type: Improvement Affects Versions: 0.4 Reporter: Keith Wall Fix For: 0.5 As raised by Robbie on the proton list (http://mail-archives.apache.org/mod_mbox/qpid-proton/201303.mbox/%3ccafitrptig+tzl-tsvjop1qdtu74mxwzqxg_lwlysdnfv9sq...@mail.gmail.com%3e) Hi all, I just noticed the maven artifactId for the proton tests for 0.4: dependency groupIdorg.apache.qpid/groupId artifactIdtests/artifactId version0.4/version /dependency Can we add 'proton' to that Id for consistency with all the other artifacts, and perhaps also help clue users in on what they actually are? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Jira numbers in commit messages
So..NO-JIRA came about for two reasons. First, as a way to escape the commit-hook level checking we voted that we wanted in order to semi-enforce that people had a JIRA in their commit log, because we were down in the ridiculous ~30% inclusion range not so many years ago. Infra ultimately said the commit-hook approach was too slow to work across the ASF-wide repo and indicated they considered the situation as I had originally: its not very hard to self-enforce you have a JIRA in all but the most trivial (readme etc) changes. Following that, we kept the NO-JIRA idea anyway for pretty much the reason Phil suggested, that by using it you are saying that you consider this to be a change that does not justify a JIRA and are willing to be especially called out if you are doing 'NO-JIRA: rewrite API' type commits. I have a script from back then sitting somewhere in the deep dark areas of my disk that pulls the commit logs and checks who has JIRAs in the messages, who doesn't, and who NO-JIRA'd somthing to allow seeing what that was. Ive been planning for a while to find it and run it again as theres been a fair bit of absue lately. I'll do it in the next week and I'll include Proton this time. Robbie On 14 March 2013 15:54, Rafael Schloming r...@alum.mit.edu wrote: Surely either way you need to read the actual log message to distinguish between correct and incorrect omission of the JIRA number. I would hate to think you'd let something like NO-JIRA: overhauled user facing API go by just because it was prefixed. ;-) --Rafael On Thu, Mar 14, 2013 at 11:38 AM, Phil Harvey p...@philharveyonline.com wrote: If I see NO-JIRA then I usually infer that the author considered whether a Jira was required and decided not. Without this marker, I can't distinguish between deliberate and accidental omission of the Jira number. On 14 March 2013 14:47, Rafael Schloming r...@alum.mit.edu wrote: To be honest, I've never really understood the point of the NO-JIRA thing. What's the technical difference between NO-JIRA: blah and simply omitting the PROTON-xxx? I can't see that it would significantly improve grepability since either way you need to run a regex over the whole log string for anything that matches PROTON-[0-9]+. --Rafael On Thu, Mar 14, 2013 at 10:31 AM, Phil Harvey p...@philharveyonline.com wrote: I notice a fair smattering of recent Proton commits without Jira numbers in them. As far as I'm aware, all commits should either contain a Jira number in the format PROTON-xyz: or, for exceptionally simple changes, NO-JIRA:. Please shout if you disagree. Thanks Phil
[jira] [Created] (PROTON-272) ctest to run python tests on an installed system.
Alan Conway created PROTON-272: -- Summary: ctest to run python tests on an installed system. Key: PROTON-272 URL: https://issues.apache.org/jira/browse/PROTON-272 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Alan Conway Assignee: Alan Conway Reduce duplication of paths etc. between config.sh and CMakeList.txt. Provide a way to run the tests on an installed system. The config.sh in the proton root directory does all the environmental configuration necessary for each of the bindings to find appropriate modules, etc. It's really handy for when you want to run code/examples on the command line out of a source tree build rather than having to install everything. I believe much of that logic is duplicated here. I know the config.sh isn't exactly cross-platform, but is there a way to eliminate or reduce some of the duplication? A related question is how to run these tests off of an installed system. Right now the tests appear to pass, however if you actually try and install the ruby binding and run anything you can't even import the module because the install is messed up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-272) Run tests on an installed system.
[ https://issues.apache.org/jira/browse/PROTON-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-272: --- Summary: Run tests on an installed system. (was: ctest to run python tests on an installed system.) Run tests on an installed system. - Key: PROTON-272 URL: https://issues.apache.org/jira/browse/PROTON-272 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Alan Conway Assignee: Alan Conway Reduce duplication of paths etc. between config.sh and CMakeList.txt. Provide a way to run the tests on an installed system. The config.sh in the proton root directory does all the environmental configuration necessary for each of the bindings to find appropriate modules, etc. It's really handy for when you want to run code/examples on the command line out of a source tree build rather than having to install everything. I believe much of that logic is duplicated here. I know the config.sh isn't exactly cross-platform, but is there a way to eliminate or reduce some of the duplication? A related question is how to run these tests off of an installed system. Right now the tests appear to pass, however if you actually try and install the ruby binding and run anything you can't even import the module because the install is messed up. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-273) Fix disabled ruby test can have nil content
Alan Conway created PROTON-273: -- Summary: Fix disabled ruby test can have nil content Key: PROTON-273 URL: https://issues.apache.org/jira/browse/PROTON-273 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Alan Conway This test: proton-c/bindings/ruby/spec/qpid/proton/message_spec.rb:404: xit can have nil content do has been disabled by replacing it with xit. The test is failing, fix the cause and re-enable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-273) Fix disabled ruby test can have nil content
[ https://issues.apache.org/jira/browse/PROTON-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-273: --- Assignee: Darryl L. Pierce Fix disabled ruby test can have nil content - Key: PROTON-273 URL: https://issues.apache.org/jira/browse/PROTON-273 Project: Qpid Proton Issue Type: Improvement Components: proton-c Reporter: Alan Conway Assignee: Darryl L. Pierce This test: proton-c/bindings/ruby/spec/qpid/proton/message_spec.rb:404: xit can have nil content do has been disabled by replacing it with xit. The test is failing, fix the cause and re-enable. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-215) Add tests to verify AMQP 1.0 type support for all language bindings
[ https://issues.apache.org/jira/browse/PROTON-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602575#comment-13602575 ] Alan Conway commented on PROTON-215: Added ruby tests: r1456613 | PROTON-215: Added ruby interop test. Add tests to verify AMQP 1.0 type support for all language bindings --- Key: PROTON-215 URL: https://issues.apache.org/jira/browse/PROTON-215 Project: Qpid Proton Issue Type: Test Components: proton-c Affects Versions: 0.3 Reporter: Ken Giusti Assignee: Alan Conway Labels: test For each language binding, we need to verify that the language can encode to and decode from the AMQP 1.0 types. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (PROTON-260) Messenger Documentation
[ https://issues.apache.org/jira/browse/PROTON-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602578#comment-13602578 ] michael goulish commented on PROTON-260: Checked in trunk/docs/messenger message_disposition.md -- rev 1456600 . Messenger Documentation --- Key: PROTON-260 URL: https://issues.apache.org/jira/browse/PROTON-260 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.5 Reporter: michael goulish Assignee: michael goulish Write documentation for the Proton Messenger interface, to include: introduction API explanations theory of operation example programs programming idioms tutorials quickstarts troubleshooting Documents should use MarkDown markup language. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RESULT] [VOTE] 0.4 RC3
On Tue, Mar 5, 2013 at 9:08 AM, Bozo Dragojevic bo...@digiverse.si wrote: Where in the repository can I see which revision/branch/tag are the release candidates? Thanks, Bozzo FYI, all the releases are now available at both https://svn.apache.org/repos/asf/qpid/proton/tags/0.x and https://svn.apache.org/repos/asf/qpid/proton/branches/0.x --Rafael
[jira] [Commented] (PROTON-215) Add tests to verify AMQP 1.0 type support for all language bindings
[ https://issues.apache.org/jira/browse/PROTON-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13602609#comment-13602609 ] Alan Conway commented on PROTON-215: It remains to add PHP tests. Add tests to verify AMQP 1.0 type support for all language bindings --- Key: PROTON-215 URL: https://issues.apache.org/jira/browse/PROTON-215 Project: Qpid Proton Issue Type: Test Components: proton-c Affects Versions: 0.3 Reporter: Ken Giusti Assignee: Alan Conway Labels: test For each language binding, we need to verify that the language can encode to and decode from the AMQP 1.0 types. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROTON-269) Connect Redirect parsing incorrectly uses position in map rather than value of key
[
https://issues.apache.org/jira/browse/PROTON-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming resolved PROTON-269.
Resolution: Fixed
Fix Version/s: 0.5
Assignee: Rafael H. Schloming
Connect Redirect parsing incorrectly uses position in map rather than value
of key
--
Key: PROTON-269
URL: https://issues.apache.org/jira/browse/PROTON-269
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Rob Godfrey
Assignee: Rafael H. Schloming
Fix For: 0.5
The connection error redirect is defined to carry an info map of the
following form:
The container is no longer available on the current connection. The peer
should attempt reconnection to the container using the details provided in
the info map.
hostname: the hostname of the container. This is the value that should be
supplied in the hostname field of the open frame, and during the SASL and TLS
negotiation (if used).
network-host: the DNS hostname or IP address of the machine hosting the
container.
port: the port number on the machine hosting the container.
However proton-c completely ignores the values of the keys in the info map
and instead assumes that network host will be the value in the second
key-value pair, and port will be the value in the thirs key-value pair; e.g.:
const char *pn_condition_redirect_host(pn_condition_t *condition)
{
pn_data_t *data = pn_condition_info(condition);
pn_data_rewind(data);
pn_data_next(data);
pn_data_enter(data);
pn_data_next(data);
pn_data_next(data);
pn_data_next(data);
pn_data_next(data);
pn_bytes_t host = pn_data_get_bytes(data);
pn_data_rewind(data);
return host.start;
}
This is incorrect behaviour.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
