Re: proton-j API factory simplification.

2013-08-02 Thread Phil Harvey
I agree that o.a.q.p.Proton is, overall, an improvement. I was partly responsible for creating the ProtonFactoryLoader and XXXFactory classes, and acknowledge that they make life too hard for the user. This was a result of trying to meet the following design goals: 1. User code should not need

Re: proton-j API factory simplification.

2013-08-02 Thread Phil Harvey
Corrected typo in the code inline: On 2 August 2013 09:44, Phil Harvey p...@philharveyonline.com wrote: I agree that o.a.q.p.Proton is, overall, an improvement. I was partly responsible for creating the ProtonFactoryLoader and XXXFactory classes, and acknowledge that they make life too hard

Re: proton-j API factory simplification.

2013-08-02 Thread Rajith Attapattu
So, I'd be in favour of Hiram's proposal if ProtonJ and ProtonC reside in proton-api.jar. This would be very easy to do, e.g. I don't think ProtonJ and ProtonC should reside in the proton-api.jar And I don't think thats what Hiram suggested either (pls correct me if I have misunderstood).

[jira] [Assigned] (PROTON-372) driver does not handle POLLHUP

2013-08-02 Thread Ted Ross (JIRA)
[ https://issues.apache.org/jira/browse/PROTON-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned PROTON-372: --- Assignee: Ted Ross driver does not handle POLLHUP --

[jira] [Commented] (PROTON-367) Provide Ruby post, fetch and mailserver examples

2013-08-02 Thread ASF subversion and git services (JIRA)
[ https://issues.apache.org/jira/browse/PROTON-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727711#comment-13727711 ] ASF subversion and git services commented on PROTON-367: Commit

[jira] [Resolved] (PROTON-367) Provide Ruby post, fetch and mailserver examples

2013-08-02 Thread Darryl L. Pierce (JIRA)
[ https://issues.apache.org/jira/browse/PROTON-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce resolved PROTON-367. - Resolution: Fixed Fix Version/s: 0.5 Provide Ruby post, fetch and mailserver

Re: proton-j API factory simplification.

2013-08-02 Thread Rob Godfrey
Given the Proton class doesn't require the user to know which implementation they are using (but allows them to explicitly ask for a particular implementation type if they so desire) I'm a little confused how adding the requirement for the user to instantiate an implementation specific class

[jira] [Created] (PROTON-387) Linked list utility code leaves dangling pointers in removed node.

2013-08-02 Thread Ken Giusti (JIRA)
Ken Giusti created PROTON-387: - Summary: Linked list utility code leaves dangling pointers in removed node. Key: PROTON-387 URL: https://issues.apache.org/jira/browse/PROTON-387 Project: Qpid Proton

[jira] [Commented] (PROTON-387) Linked list utility code leaves dangling pointers in removed node.

2013-08-02 Thread ASF subversion and git services (JIRA)
[ https://issues.apache.org/jira/browse/PROTON-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13727894#comment-13727894 ] ASF subversion and git services commented on PROTON-387: Commit

[jira] [Resolved] (PROTON-387) Linked list utility code leaves dangling pointers in removed node.

2013-08-02 Thread Ken Giusti (JIRA)
[ https://issues.apache.org/jira/browse/PROTON-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti resolved PROTON-387. --- Resolution: Fixed Linked list utility code leaves dangling pointers in removed node.

Re: proton-j API factory simplification.

2013-08-02 Thread Rafael Schloming
Say you have a user who is intentionally dependent on the ProtonJ implementation (e.g. hiram). He now needs to write code that looks like this: Connection conn = discoveryMechanism(...); ProtonJConnection jconn = (ProtonJConnection) conn; This is basically analogous to asking all