[jira] [Commented] (QPID-3364) Segmentation fault when unloading shared libraries linked with libqpidmessaging

[ https://issues.apache.org/jira/browse/QPID-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248143#comment-13248143 ] Paul Colby commented on QPID-3364: -- A not-so-quick heuristically driven binary search has

Re: Review Request: Destination refactoring

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4658/#review6737 --- This looks like a good start, but I am rather concerned at the

[jira] [Commented] (QPID-3401) Refactor address resolution code

[ https://issues.apache.org/jira/browse/QPID-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248226#comment-13248226 ] jirapos...@reviews.apache.org commented on QPID-3401: -

[jira] [Updated] (QPID-3027) PHP binding of Qpid Messaging API

[ https://issues.apache.org/jira/browse/QPID-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Colby updated QPID-3027: - Attachment: cqpid_php.20120406.diff cqpid_php.20120406.diff Changes in this version: * fixed a bug

[jira] [Assigned] (QPID-3911) Consumer.close() and session.rollback() deadlocks

[ https://issues.apache.org/jira/browse/QPID-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3911: Assignee: Robbie Gemmell (was: Alex Rudyy) Consumer.close() and session.rollback()

[jira] [Resolved] (QPID-3911) Consumer.close() and session.rollback() deadlocks

[ https://issues.apache.org/jira/browse/QPID-3911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3911. -- Resolution: Fixed Fix Version/s: 0.17 Rob and I both looked over the patch separately

[jira] [Commented] (QPID-3401) Refactor address resolution code

[ https://issues.apache.org/jira/browse/QPID-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13248234#comment-13248234 ] jirapos...@reviews.apache.org commented on QPID-3401: -

Re: Integrating destination patch into the code base

Option 1 seems like the only sensible course of action, options 2 and 3 would just be continuing further down the paths that lead us where we are now. At the end of this process there should really be less arbitrary segregation of codepaths and less legacy cruft lying around, not more of it.

Re: Integrating destination patch into the code base

On 6 April 2012 13:31, Robbie Gemmell robbie.gemm...@gmail.com wrote: Option 1 seems like the only sensible course of action, options 2 and 3 would just be continuing further down the paths that lead us where we are now. At the end of this process there should really be less arbitrary

Re: Integrating destination patch into the code base

I should have added, I think the work so far should continue to live on its branch because until integrating it with the rest of the client (which is the more interesting bit to the puzzle) really gets underway the approach is still really unproven and there is little benefit to it being on trunk

Re: Qpid non jndi

Hi Eugene, There have certainly been users on the list over the years using the client in osgi environments which suggests it is possible to make that work. I dont really have any experience there to help on that front, however I can answer the question you have asked... The JNDI context

Re: Integrating destination patch into the code base

Thanks Guy for the feedback ! Lets focus on option #1. Robbie I would need a bit of help with integrating into the 0-8 codepath :) I also agree that the work should be on the branch until we are satisfied with the integration. The bulk of the work and the risk involved is primarily in this part.