[jira] [Commented] (PROTON-1044) Create/Delete of BlockingConnection leaks file descriptors

2016-01-19 Thread Gordon Sim (JIRA)

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

2016-01-19 Thread Robbie Gemmell
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 Stitcher  wrote:
> 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

2016-01-19 Thread astitcher
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 Stitcher 
Date:   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

2016-01-19 Thread tourili
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

2016-01-19 Thread ASF GitHub Bot (JIRA)

[ 
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

2016-01-19 Thread alanconway
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...

2016-01-19 Thread tourili
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.

2016-01-19 Thread Justin Ross
Okay, not a problem.  I'll adjust the schedule on the release page.

Justin

On Tue, Jan 19, 2016 at 11:57 AM, Alan Conway  wrote:

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

2016-01-19 Thread gemmellr
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

2016-01-19 Thread ASF subversion and git services (JIRA)

[ 
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

2016-01-19 Thread ASF GitHub Bot (JIRA)

[ 
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

2016-01-19 Thread Robbie Gemmell (JIRA)

 [ 
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

2016-01-19 Thread Robbie Gemmell (JIRA)

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

2016-01-19 Thread tourili
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

2016-01-19 Thread Robbie Gemmell
On 19 January 2016 at 15:15, tourili  wrote:
> 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...

2016-01-19 Thread gemmellr
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

2016-01-19 Thread ASF GitHub Bot (JIRA)

[ 
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

2016-01-19 Thread ASF GitHub Bot (JIRA)

[ 
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

2016-01-19 Thread Tomas Soltys (JIRA)

[ 
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

2016-01-19 Thread Tomas Soltys (JIRA)

 [ 
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

2016-01-19 Thread Tomas Soltys (JIRA)

 [ 
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

2016-01-19 Thread Tomas Soltys (JIRA)

 [ 
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

2016-01-19 Thread Tomas Soltys (JIRA)

 [ 
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

2016-01-19 Thread Tomas Soltys (JIRA)

 [ 
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

2016-01-19 Thread Justin Ross (JIRA)

[ 
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

2016-01-19 Thread ASF subversion and git services (JIRA)

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

2016-01-19 Thread asfgit
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

2016-01-19 Thread ASF GitHub Bot (JIRA)

[ 
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

2016-01-19 Thread tourili
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...

2016-01-19 Thread SreeramGarlapati
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]

2016-01-19 Thread Robbie Gemmell
On 19 January 2016 at 15:25, Andrew Stitcher  wrote:
> 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