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 collecti
[
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.
>
[
https://issues.apache.org/jira/browse/PROTON-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13727894#comment-13727894
]
ASF subversion and git services commented on PROTON-387:
Commit 15
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
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 actual
[
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
[
https://issues.apache.org/jira/browse/PROTON-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13727711#comment-13727711
]
ASF subversion and git services commented on PROTON-367:
Commit 15
[
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
> --
>
>
On Fri, Aug 2, 2013 at 4:44 AM, Phil Harvey 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 for the user.
>
> This was a result of trying to mee
>
> 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)
Corrected typo in the code inline:
On 2 August 2013 09:44, Phil Harvey 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 for the user.
>
> This
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 to
12 matches
Mail list logo