[jira] [Commented] (PROTON-1044) Create/Delete of BlockingConnection leaks file descriptors
[ https://issues.apache.org/jira/browse/PROTON-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106485#comment-15106485 ] Gordon Sim commented on PROTON-1044: Thanks for confirming Jeff! > Create/Delete of BlockingConnection leaks file descriptors > -- > > Key: PROTON-1044 > URL: https://issues.apache.org/jira/browse/PROTON-1044 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.9 > Environment: Fedora 22 >Reporter: Jeff Ortel > Attachments: jortel.py > > > Each time a BlockingConnection is created, it creates a Container. The > Container() opens (2) file descriptors which are never closed. The result is > that (2) file descriptors are leaked for each time BlockingConnection() is > called even if properly closed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Please update appveyor.yml version [Was: Proton 0.12.0 release update - Alpha is available]
Can I suggest a more basic change of simply removing the release version from the Appveyor job id? None of the other CI jobs have that, and given it has been wrong for around 5 months it doesn't seem particularly noted by most folks. The branch name could still be there as it is now, which in many cases would convey a similar level of information. Robbie On 18 January 2016 at 19:57, Andrew Stitcherwrote: > A small request for the release manager: > > could you please add updating the appveyor.yml file to the correct > version to the release process. > > I've just noticed that the appveyor build still thinks the build > version is 0.10-SNAPSHOT. This strongly implies that the master > appveyor.yml has not been updated in 2 releases. > > This is not terrible, but it is a bit confusing when you go to the > appveyor website and see status of our builds. > > [I've update master to 0.12-SNAPSHOT now, but the beta branch will need > updating to 0.12 and the master branch to 0.13-SNAPSHOT or whatever we > call the next release of proton] > > Thanks > > Andrew > > On Wed, 2016-01-13 at 17:21 -0800, Justin Ross wrote: >> Hello, everyone. It's time for the Proton 0.12.0 alpha. >> >> Revision: 576f656b on master >> Artifacts: >> https://dist.apache.org/repos/dist/dev/qpid/proton/0.12.0-alpha/ >> Test output: >> http://people.apache.org/~jross/qpid-releases/quirk-proton-0.12.0-alp >> ha.log >> >> See the release page[1] for more information about the schedule and >> criteria for accepting changes. >> >> We branch for release in *one week*. Start your testing early. >> >> Thanks! >> Justin >> >> --- >> [1] Proton 0.12.0 release page: >> https://cwiki.apache.org/confluence/display/qpid/Qpid+Proton+0.12.0 > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org >
[GitHub] qpid-proton pull request: Event tidying
GitHub user astitcher opened a pull request: https://github.com/apache/qpid-proton/pull/63 Event tidying Pull request for comment by @alanconway & @cliffjansen These changes passed the tests on travis and appveyor for me, so hopefully they work. You can merge this pull request into a Git repository by running: $ git pull https://github.com/astitcher/qpid-proton event_tidying Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/63.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #63 commit a30ad539aa89a922ec19e9456fcf2c67fe4daa1e Author: Andrew StitcherDate: 2016-01-18T23:42:58Z PROTON-1083: [C++ binding] Rearrange handler hierarchy - User handlers are messaging_handler - User has no access to lower level proton_handler x Order of handler processing is subtly different now -- flow controller gets called after user event handler not before commit 44049b46c1432c0c341e87df09eb52776ffd2cc5 Author: Andrew Stitcher Date: 2016-01-19T15:13:07Z PROTON-1083: Simplified event so that there is no actual hierarchy of events commit d2337e255713b234eadbe5233eb4f1cf11cfa384 Author: Andrew Stitcher Date: 2016-01-19T19:50:56Z PROTON-1083: [C++ binding] Finish completely separating internal/API handlers and events - There is now no inheritance relationship between proton_handler and messaging_handler - No inheritance relationship between proton_event and messaging_event/event - Removed the old handler completely - Removed a load of dynamic_casts that are now unnecessary - A bunch of header include tidies up. commit 90c3a979b233dff623e5c95b504745081121e0bc Author: Andrew Stitcher Date: 2016-01-19T20:41:40Z PROTON-1083: [C++ binding] Renamed messaging_handler as simply handler - Now the API visible objects are proton::event & proton::handler commit 711dcd603edebd62300a9d6aa538e3741ca6d3cd Author: Andrew Stitcher Date: 2016-01-19T20:58:21Z NO-JIRA: removed unnecessary declarations --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Android client / ServiceBus
Thanks a lot for your input Robbie Robbie Gemmell wrote > I'm afraid I don't have any real experience of using Event Hubs, > Android, Messenger, or combinations thereof, instead mostly > using/developing proton-j as a pure protocol engine used within other > components such as the JMS client or brokers like ActiveMQ. I can > however try to answer some of your questions. You are already helping me a lot Robbie Gemmell wrote > The 'AndroidProton' you referred to in your original post looks to be > a wrapper of a JNI based Java binding for proton-c which existed in > the main repo previously. That JNI binging was removed perhaps a > couple of years ago or longer. You are right, it is a full JNI implementation thanks to the authors' job Robbie Gemmell wrote > The reactive work is more developed in the other languages/bindings, > but there is a Reactor impl in proton-j that could form the basis ... That sounds good. I'm complete newb in the proton project, so I have to do a little digging in the project. Having android native implementation in proton sound interesting in this nice project. A lot of devices out there are android based, and Amqp will be required for a lot IoT backends (Azure in instance) on such device. @tourili -- View this message in context: http://qpid.2158936.n2.nabble.com/Android-client-ServiceBus-tp7636619p7636863.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
[jira] [Commented] (PROTON-1096) [proton-j] enable set/get of MessageFormat on the Delivery being sent/received
[ https://issues.apache.org/jira/browse/PROTON-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15107378#comment-15107378 ] ASF GitHub Bot commented on PROTON-1096: Github user tourili commented on the pull request: https://github.com/apache/qpid-proton/pull/53#issuecomment-172977081 Thank you. Sorry for hijacking this thread. I am answering you on the mailing list... > [proton-j] enable set/get of MessageFormat on the Delivery being > sent/received > --- > > Key: PROTON-1096 > URL: https://issues.apache.org/jira/browse/PROTON-1096 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-j >Affects Versions: 0.12.0 >Reporter: Sreeram Garlapati >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > Original Estimate: 4h > Remaining Estimate: 4h > > This is a feature request from windows azure eventhubs team. Here's the pull > request: https://github.com/apache/qpid-proton/pull/53 > I (sreeram, from windows azure eventHubs team) am building eventHubs Java > client SDK and taking a dependency on proton-j (which will be available on > GitHub, hopefully, soon) for Amqp. > EventHubs amqp client will need to set a Custom MessageFormat to enable a > Critical scenario for Sending (Send Batch) messages to EventHubs from our > JavaClient. > Delivery class, currently, already has a getMessageFormat().. I extended this > to also have setMessageFormat() method which should be copied to the Transfer > frame. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: Event tidying
Github user alanconway commented on the pull request: https://github.com/apache/qpid-proton/pull/63#issuecomment-173013404 Ship it! Neater and cleaner, I rebased my connection_engine branch on it, the only changes I had to make were simpifications to the dispatch loop, everything works. I'll wait for this to go in before I commit the engine stuff. If you want to look at latest engine see: https://github.com/alanconway/qpid-proton/tree/cpp-engine-examples --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] qpid-proton pull request: [PROTON-1096]: expose seting MessageForm...
Github user tourili commented on the pull request: https://github.com/apache/qpid-proton/pull/53#issuecomment-172977081 Thank you. Sorry for hijacking this thread. I am answering you on the mailing list... --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Request delay of proton 0.12 beta.
Okay, not a problem. I'll adjust the schedule on the release page. Justin On Tue, Jan 19, 2016 at 11:57 AM, Alan Conwaywrote: > We are working hard on the C++ binding, which will include a > "connection_engine" as an alternative to the reactor, I'll post another > note on why and how it is different. Probably not going to be ready to > go on Wed, can we postpone the Beta till Monday? > > Cheers, > Alan. > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
[GitHub] qpid-proton pull request: [PROTON-1096]: expose seting MessageForm...
Github user gemmellr commented on the pull request: https://github.com/apache/qpid-proton/pull/53#issuecomment-172958834 I have replied to your thread on the mailing list, please keep general discussion there. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-1096) [proton-j] enable set/get of MessageFormat on the Delivery being sent/received
[ https://issues.apache.org/jira/browse/PROTON-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15107102#comment-15107102 ] ASF subversion and git services commented on PROTON-1096: - Commit babdc005adcefc0512403319ee28b8e14c8a6356 in qpid-proton's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=babdc00 ] PROTON-1096: change the get/set method sigs [back] to use int, avoid a breaking change for little real world benefit. Mention PR #53 to add reference. > [proton-j] enable set/get of MessageFormat on the Delivery being > sent/received > --- > > Key: PROTON-1096 > URL: https://issues.apache.org/jira/browse/PROTON-1096 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-j >Affects Versions: 0.12.0 >Reporter: Sreeram Garlapati >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > Original Estimate: 4h > Remaining Estimate: 4h > > This is a feature request from windows azure eventhubs team. Here's the pull > request: https://github.com/apache/qpid-proton/pull/53 > I (sreeram, from windows azure eventHubs team) am building eventHubs Java > client SDK and taking a dependency on proton-j (which will be available on > GitHub, hopefully, soon) for Amqp. > EventHubs amqp client will need to set a Custom MessageFormat to enable a > Critical scenario for Sending (Send Batch) messages to EventHubs from our > JavaClient. > Delivery class, currently, already has a getMessageFormat().. I extended this > to also have setMessageFormat() method which should be copied to the Transfer > frame. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1096) [proton-j] enable set/get of MessageFormat on the Delivery being sent/received
[ https://issues.apache.org/jira/browse/PROTON-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15107119#comment-15107119 ] ASF GitHub Bot commented on PROTON-1096: Github user gemmellr commented on the pull request: https://github.com/apache/qpid-proton/pull/53#issuecomment-172938973 Hi Sreeram, As you might have already seen from the JIRA update or commit just now, I have made a further update here to go back to using an int to carry the 32bit value for the message format. My change to use a long had caused some compatibility issues that I don't think it is important enough a change to warrant, so I've put it back to the int. If you were just using an int (as your original PR would have needed), or perhaps explicitly casting a long to int, then you shouldnt have to change anything, but if you were now passing in a long directly after the earlier changes you will need to make some updates too, in which case apologies for any hassle caused. Robbie > [proton-j] enable set/get of MessageFormat on the Delivery being > sent/received > --- > > Key: PROTON-1096 > URL: https://issues.apache.org/jira/browse/PROTON-1096 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-j >Affects Versions: 0.12.0 >Reporter: Sreeram Garlapati >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > Original Estimate: 4h > Remaining Estimate: 4h > > This is a feature request from windows azure eventhubs team. Here's the pull > request: https://github.com/apache/qpid-proton/pull/53 > I (sreeram, from windows azure eventHubs team) am building eventHubs Java > client SDK and taking a dependency on proton-j (which will be available on > GitHub, hopefully, soon) for Amqp. > EventHubs amqp client will need to set a Custom MessageFormat to enable a > Critical scenario for Sending (Send Batch) messages to EventHubs from our > JavaClient. > Delivery class, currently, already has a getMessageFormat().. I extended this > to also have setMessageFormat() method which should be copied to the Transfer > frame. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (PROTON-1096) [proton-j] enable set/get of MessageFormat on the Delivery being sent/received
[ https://issues.apache.org/jira/browse/PROTON-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened PROTON-1096: Reopening. While I was expanding the changes proposed in the PR to cover received Deliveries as well, I changed the method signatures from using int to using long so that the 32bit message format would be represented using positive long values only. I have since come to find this causes runtime but not compile time compatibility issues for some of the things out there already using the existing method, so given that I think reverting to use of int as originally present/proposed would be prudent given the limited real world benefit of the alternative. > [proton-j] enable set/get of MessageFormat on the Delivery being > sent/received > --- > > Key: PROTON-1096 > URL: https://issues.apache.org/jira/browse/PROTON-1096 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-j >Affects Versions: 0.12.0 >Reporter: Sreeram Garlapati >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > Original Estimate: 4h > Remaining Estimate: 4h > > This is a feature request from windows azure eventhubs team. Here's the pull > request: https://github.com/apache/qpid-proton/pull/53 > I (sreeram, from windows azure eventHubs team) am building eventHubs Java > client SDK and taking a dependency on proton-j (which will be available on > GitHub, hopefully, soon) for Amqp. > EventHubs amqp client will need to set a Custom MessageFormat to enable a > Critical scenario for Sending (Send Batch) messages to EventHubs from our > JavaClient. > Delivery class, currently, already has a getMessageFormat().. I extended this > to also have setMessageFormat() method which should be copied to the Transfer > frame. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-1096) [proton-j] enable set/get of MessageFormat on the Delivery being sent/received
[ https://issues.apache.org/jira/browse/PROTON-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved PROTON-1096. Resolution: Fixed > [proton-j] enable set/get of MessageFormat on the Delivery being > sent/received > --- > > Key: PROTON-1096 > URL: https://issues.apache.org/jira/browse/PROTON-1096 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-j >Affects Versions: 0.12.0 >Reporter: Sreeram Garlapati >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > Original Estimate: 4h > Remaining Estimate: 4h > > This is a feature request from windows azure eventhubs team. Here's the pull > request: https://github.com/apache/qpid-proton/pull/53 > I (sreeram, from windows azure eventHubs team) am building eventHubs Java > client SDK and taking a dependency on proton-j (which will be available on > GitHub, hopefully, soon) for Amqp. > EventHubs amqp client will need to set a Custom MessageFormat to enable a > Critical scenario for Sending (Send Batch) messages to EventHubs from our > JavaClient. > Delivery class, currently, already has a getMessageFormat().. I extended this > to also have setMessageFormat() method which should be copied to the Transfer > frame. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: [PROTON-1096]: expose seting MessageForm...
Github user tourili commented on the pull request: https://github.com/apache/qpid-proton/pull/53#issuecomment-172944770 Hi I have a question about the proton-j. Is proton-j a valid option for developing **android client** to connect to **azure service bus**. Please if any one can confirm a way or another to acheive this. I appreciate a lot Thanks --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Android client / ServiceBus
On 19 January 2016 at 15:15, touriliwrote: > Any hint from some experimented with this topic PLEASE > > > > -- > View this message in context: > http://qpid.2158936.n2.nabble.com/Android-client-ServiceBus-tp7636619p7636821.html > Sent from the Apache Qpid Proton mailing list archive at Nabble.com. Hi tourili, I'm afraid I don't have any real experience of using Event Hubs, Android, Messenger, or combinations thereof, instead mostly using/developing proton-j as a pure protocol engine used within other components such as the JMS client or brokers like ActiveMQ. I can however try to answer some of your questions. The 'AndroidProton' you referred to in your original post looks to be a wrapper of a JNI based Java binding for proton-c which existed in the main repo previously. That JNI binging was removed perhaps a couple of years ago or longer. Messenger in general is not seeing a lot of activity of late (and never really did for its proton-j port), with most developer attention recently instead going toward more general reactive API work. The reactive work is more developed in the other languages/bindings, but there is a Reactor impl in proton-j that could form the basis of some of the slightly higher level work done in the other languages. I dont have any real experience with this either, but I believe folks are using it directly already to implement their applications/clients. You can see some example of it in the examples/java/reactor dir, e.g. the Send class (the Recv class actually is a listener that accepts incoming connections, such as those made by Recv). Robbie
[GitHub] qpid-proton pull request: [PROTON-1096]: expose seting MessageForm...
Github user gemmellr commented on the pull request: https://github.com/apache/qpid-proton/pull/53#issuecomment-172938973 Hi Sreeram, As you might have already seen from the JIRA update or commit just now, I have made a further update here to go back to using an int to carry the 32bit value for the message format. My change to use a long had caused some compatibility issues that I don't think it is important enough a change to warrant, so I've put it back to the int. If you were just using an int (as your original PR would have needed), or perhaps explicitly casting a long to int, then you shouldnt have to change anything, but if you were now passing in a long directly after the earlier changes you will need to make some updates too, in which case apologies for any hassle caused. Robbie --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-1096) [proton-j] enable set/get of MessageFormat on the Delivery being sent/received
[ https://issues.apache.org/jira/browse/PROTON-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15107251#comment-15107251 ] ASF GitHub Bot commented on PROTON-1096: Github user gemmellr commented on the pull request: https://github.com/apache/qpid-proton/pull/53#issuecomment-172958834 I have replied to your thread on the mailing list, please keep general discussion there. > [proton-j] enable set/get of MessageFormat on the Delivery being > sent/received > --- > > Key: PROTON-1096 > URL: https://issues.apache.org/jira/browse/PROTON-1096 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-j >Affects Versions: 0.12.0 >Reporter: Sreeram Garlapati >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > Original Estimate: 4h > Remaining Estimate: 4h > > This is a feature request from windows azure eventhubs team. Here's the pull > request: https://github.com/apache/qpid-proton/pull/53 > I (sreeram, from windows azure eventHubs team) am building eventHubs Java > client SDK and taking a dependency on proton-j (which will be available on > GitHub, hopefully, soon) for Amqp. > EventHubs amqp client will need to set a Custom MessageFormat to enable a > Critical scenario for Sending (Send Batch) messages to EventHubs from our > JavaClient. > Delivery class, currently, already has a getMessageFormat().. I extended this > to also have setMessageFormat() method which should be copied to the Transfer > frame. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1096) [proton-j] enable set/get of MessageFormat on the Delivery being sent/received
[ https://issues.apache.org/jira/browse/PROTON-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15107785#comment-15107785 ] ASF GitHub Bot commented on PROTON-1096: Github user SreeramGarlapati commented on the pull request: https://github.com/apache/qpid-proton/pull/53#issuecomment-173046439 Not a problem Robbie! Will merge this soon. Thanks for the Update! > [proton-j] enable set/get of MessageFormat on the Delivery being > sent/received > --- > > Key: PROTON-1096 > URL: https://issues.apache.org/jira/browse/PROTON-1096 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-j >Affects Versions: 0.12.0 >Reporter: Sreeram Garlapati >Assignee: Robbie Gemmell > Fix For: 0.12.0 > > Original Estimate: 4h > Remaining Estimate: 4h > > This is a feature request from windows azure eventhubs team. Here's the pull > request: https://github.com/apache/qpid-proton/pull/53 > I (sreeram, from windows azure eventHubs team) am building eventHubs Java > client SDK and taking a dependency on proton-j (which will be available on > GitHub, hopefully, soon) for Amqp. > EventHubs amqp client will need to set a Custom MessageFormat to enable a > Critical scenario for Sending (Send Batch) messages to EventHubs from our > JavaClient. > Delivery class, currently, already has a getMessageFormat().. I extended this > to also have setMessageFormat() method which should be copied to the Transfer > frame. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15108149#comment-15108149 ] Tomas Soltys edited comment on PROTON-515 at 1/20/16 7:20 AM: -- Removed not needed patches from attachment and added additional patches required for proton to be working on OpenVMS. was (Author: solttom): Additional patches required for proton to be working on OpenVMS. > Port to OpenVMS > --- > > Key: PROTON-515 > URL: https://issues.apache.org/jira/browse/PROTON-515 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Environment: OpenVMS >Reporter: Tomas Soltys > Labels: OpenVMS, patch > Attachments: io.c.patch, object.h.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Soltys updated PROTON-515: Attachment: object.h.patch io.c.patch Additional patches required for proton to be working on OpenVMS. > Port to OpenVMS > --- > > Key: PROTON-515 > URL: https://issues.apache.org/jira/browse/PROTON-515 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.6 > Environment: OpenVMS >Reporter: Tomas Soltys > Labels: OpenVMS, patch > Attachments: codec.c.patch, driver.c.patch, io.c.patch, > message.c.patch, object.h.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Soltys updated PROTON-515: Attachment: (was: codec.c.patch) > Port to OpenVMS > --- > > Key: PROTON-515 > URL: https://issues.apache.org/jira/browse/PROTON-515 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Environment: OpenVMS >Reporter: Tomas Soltys > Labels: OpenVMS, patch > Attachments: io.c.patch, object.h.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Soltys updated PROTON-515: Attachment: (was: message.c.patch) > Port to OpenVMS > --- > > Key: PROTON-515 > URL: https://issues.apache.org/jira/browse/PROTON-515 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Environment: OpenVMS >Reporter: Tomas Soltys > Labels: OpenVMS, patch > Attachments: io.c.patch, object.h.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Soltys updated PROTON-515: Attachment: (was: driver.c.patch) > Port to OpenVMS > --- > > Key: PROTON-515 > URL: https://issues.apache.org/jira/browse/PROTON-515 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Environment: OpenVMS >Reporter: Tomas Soltys > Labels: OpenVMS, patch > Attachments: io.c.patch, object.h.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Soltys updated PROTON-515: Affects Version/s: (was: 0.6) 0.11.1 > Port to OpenVMS > --- > > Key: PROTON-515 > URL: https://issues.apache.org/jira/browse/PROTON-515 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 > Environment: OpenVMS >Reporter: Tomas Soltys > Labels: OpenVMS, patch > Attachments: io.c.patch, object.h.patch > > > There is a need for proton-c port to OpenVMS platform. > To make proton-c functional on OpenVMS few changes in the source code are > required. > Here is list of files I have identified which require some attention: > proton-c/src/platform_fmt.h > proton-c/src/posix/driver.c > proton-c/src/object/object.c > proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1088) Add convenience functions to obtain the client certificate fingerprint, subject subfields
[ https://issues.apache.org/jira/browse/PROTON-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106717#comment-15106717 ] Justin Ross commented on PROTON-1088: - I don't think the patch on this one is ready. The names of the constants and methods differ. The number of new methods in Python is large, and it's not clear to me why we need this many convenience accessors. Many of these no-arg accessors are named get_something, where the Proton style is to use property accessors without get_. Indeed the patch itself does this in one instance, but not others. IMO, since this is public API and not just an implementation detail, this hasn't received enough attention to go in for 0.12.0 at this point. > Add convenience functions to obtain the client certificate fingerprint, > subject subfields > - > > Key: PROTON-1088 > URL: https://issues.apache.org/jira/browse/PROTON-1088 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.12.0 > > > 1. Provide a convenience function which will return a an ssl certificate > fingerprint (a sha1 or sha256 hash of the certificate). > -- When you look go to a https site via a web browser, you can look at the > certificate fingerprint by clicking the View Certificate button on the > browser. Add a convenience function to proton which will return the char > array of octets. sha1 hashing produces a 20 octet hash and sha256 provides a > 32 octet hash. The function signature should approximately look like this - > void pn_ssl_get_fingerprint(pn_ssl_t \*ssl0, unsigned char \*md, const char* > digest_name) > 2. The subject field on the SSL cert has many subfields like - > C = ISO3166 two character country code > ST = state or province > L = Locality; generally means city > O = Organization - Company Name > OU = Organization Unit - division or unit > CN = CommonName - end entity name e.g. www.example.com > Provide convenience functions to obtain values of the above subfields. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-1088) Add convenience functions to obtain the client certificate fingerprint, subject subfields
[ https://issues.apache.org/jira/browse/PROTON-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106762#comment-15106762 ] ASF subversion and git services commented on PROTON-1088: - Commit 1b3e5512fd6fbb04d50623f06c2ace6a53130f9f in qpid-proton's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1b3e551 ] PROTON-1088 - Additional fix, added schannel.c and ssl_stub.c stubs > Add convenience functions to obtain the client certificate fingerprint, > subject subfields > - > > Key: PROTON-1088 > URL: https://issues.apache.org/jira/browse/PROTON-1088 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.12.0 > > > 1. Provide a convenience function which will return a an ssl certificate > fingerprint (a sha1 or sha256 hash of the certificate). > -- When you look go to a https site via a web browser, you can look at the > certificate fingerprint by clicking the View Certificate button on the > browser. Add a convenience function to proton which will return the char > array of octets. sha1 hashing produces a 20 octet hash and sha256 provides a > 32 octet hash. The function signature should approximately look like this - > void pn_ssl_get_fingerprint(pn_ssl_t \*ssl0, unsigned char \*md, const char* > digest_name) > 2. The subject field on the SSL cert has many subfields like - > C = ISO3166 two character country code > ST = state or province > L = Locality; generally means city > O = Organization - Company Name > OU = Organization Unit - division or unit > CN = CommonName - end entity name e.g. www.example.com > Provide convenience functions to obtain values of the above subfields. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] qpid-proton pull request: PROTON-1088 - Additional fix, added scha...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/62 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PROTON-1088) Add convenience functions to obtain the client certificate fingerprint, subject subfields
[ https://issues.apache.org/jira/browse/PROTON-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15106763#comment-15106763 ] ASF GitHub Bot commented on PROTON-1088: Github user asfgit closed the pull request at: https://github.com/apache/qpid-proton/pull/62 > Add convenience functions to obtain the client certificate fingerprint, > subject subfields > - > > Key: PROTON-1088 > URL: https://issues.apache.org/jira/browse/PROTON-1088 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.11.1 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.12.0 > > > 1. Provide a convenience function which will return a an ssl certificate > fingerprint (a sha1 or sha256 hash of the certificate). > -- When you look go to a https site via a web browser, you can look at the > certificate fingerprint by clicking the View Certificate button on the > browser. Add a convenience function to proton which will return the char > array of octets. sha1 hashing produces a 20 octet hash and sha256 provides a > 32 octet hash. The function signature should approximately look like this - > void pn_ssl_get_fingerprint(pn_ssl_t \*ssl0, unsigned char \*md, const char* > digest_name) > 2. The subject field on the SSL cert has many subfields like - > C = ISO3166 two character country code > ST = state or province > L = Locality; generally means city > O = Organization - Company Name > OU = Organization Unit - division or unit > CN = CommonName - end entity name e.g. www.example.com > Provide convenience functions to obtain values of the above subfields. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Android client / ServiceBus
Any hint from some experimented with this topic PLEASE -- View this message in context: http://qpid.2158936.n2.nabble.com/Android-client-ServiceBus-tp7636619p7636821.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
[GitHub] qpid-proton pull request: [PROTON-1096]: expose seting MessageForm...
Github user SreeramGarlapati commented on the pull request: https://github.com/apache/qpid-proton/pull/53#issuecomment-173046439 Not a problem Robbie! Will merge this soon. Thanks for the Update! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
Re: Please update appveyor.yml version [Was: Proton 0.12.0 release update - Alpha is available]
On 19 January 2016 at 15:25, Andrew Stitcherwrote: > On Tue, 2016-01-19 at 10:39 +, Robbie Gemmell wrote: >> Can I suggest a more basic change of simply removing the release >> version from the Appveyor job id? >> >> None of the other CI jobs have that, and given it has been wrong for >> around 5 months it doesn't seem particularly noted by most folks. The >> branch name could still be there as it is now, which in many cases >> would convey a similar level of information. > > That would work, but with some work as the version is part of the > identifying info for a build. I think you could change that but it is > there currently. > > Andrew > I think changing the job version format should be ok. The job version currently has a/the proton version, branch name, and finally the auto-incrementing job build number in it, meaning there isn't really a way you can determine in advance what a particular job version will be currently anyway (other than picking up the 'latest' one, or all those on a given branch). I'll remove the proton version from the job version now. Shout if it causes a problem folks. Robbie