[
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.diff
Initial C++ Messaging API binding for PHP.
PHP binding of Qpid Messaging API
[
https://issues.apache.org/jira/browse/QPID-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12991848#comment-12991848
]
Paul Colby commented on QPID-3027:
--
I've just attached an initial PHP binding. This
[
https://issues.apache.org/jira/browse/QPID-2900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated QPID-2900:
-
Status: Ready To Review (was: In Progress)
CommitRollbackTest#testGetThenRollback and
I think trying to clean up how people use the codebase is a good idea,
no question about that. However, as there is already a
ConnectionFactory implementation that people simply miss/ignore
already when overlooking/ignoring JNDI I do wonder if providing a
ConnectionFactory..Factory..is actually
I largely agree with Rajith as shown by my commit history, there are
some changes I dont think warrant a JIRA such as random litle README
or website changes (however, larger documentation changes should
generally be associated with a JIRA because surely they are
documenting something that was
On Tue, Feb 8, 2011 at 8:14 AM, Robbie Gemmell robbie.gemm...@gmail.comwrote:
I largely agree with Rajith as shown by my commit history, there are
some changes I dont think warrant a JIRA such as random litle README
or website changes (however, larger documentation changes should
generally be
Adding the tag after the fact does nothing to fix the commits where it
was missing at the time, because JIRA and associated tools work off
the original commit emails and so updating the log property afterwards
doesn't fix that. Always being able to 'accidentally' forget to
create/include a
For example, this commit should have had a JIRA, and the commit it
reverts had a JIRA listed. However, looking at the commit tab on that
JIRA in future there will be no indication this revert occured.
URL: http://svn.apache.org/viewvc?rev=1068417view=rev
Log:
Reverts r1068042.
We will fix this
On Tue, 2011-02-08 at 13:14 +, Robbie Gemmell wrote:
I largely agree with Rajith as shown by my commit history, there are
some changes I dont think warrant a JIRA such as random litle README
or website changes (however, larger documentation changes should
generally be associated with a
Implement JCA Adapter for Java JMS client
-
Key: QPID-3044
URL: https://issues.apache.org/jira/browse/QPID-3044
Project: Qpid
Issue Type: Improvement
Components: Java Client
Affects
[
https://issues.apache.org/jira/browse/QPID-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated QPID-3044:
--
Issue Type: New Feature (was: Improvement)
Implement JCA Adapter for Java JMS client
Bug 675921 - clustered qpidd broker fails ocassionly the
cluster_tests.ShortTests.test_route_update
---
Key: QPID-3045
URL:
[
https://issues.apache.org/jira/browse/QPID-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated QPID-3045:
--
Fix Version/s: 0.9
Bug 675921 - clustered qpidd broker fails ocassionly the
[
https://issues.apache.org/jira/browse/QPID-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992025#comment-12992025
]
Ken Giusti commented on QPID-2935:
--
Status update 2/7/2011:
Resync'ed to trunk.
Fixed:
-)
On 02/08/2011 03:15 PM, Robbie Gemmell wrote:
We could allow certain things through the hook, eg putting NO-JIRA in
the commit log bypasses it. That could presumably also be stripped by
the hook on success, and be indicated in any failure message to ensure
people always know its an option. That
[
https://issues.apache.org/jira/browse/QPID-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992031#comment-12992031
]
Gordon Sim commented on QPID-529:
-
Initial implementation available for review:
[
https://issues.apache.org/jira/browse/QPID-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated QPID-529:
Due Date: 16/Feb/11 (was: 18/Feb/11)
Support message priority
[
https://issues.apache.org/jira/browse/QPID-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992034#comment-12992034
]
Gordon Sim commented on QPID-2104:
--
Patch including this fix available for review:
[
https://issues.apache.org/jira/browse/QPID-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated QPID-2104:
-
Fix Version/s: 0.9
Improved LVQ implementation
---
Key:
[
https://issues.apache.org/jira/browse/QPID-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gordon Sim updated QPID-2104:
-
Due Date: 16/Feb/11
Description:
My view of what ideal 'LVQ' behaviour would be like is that the
Appreciate any help...
On Tue, 2011-02-08 at 11:29 -0600, Kerry Bonin wrote:
Appreciate any help...
Could you be a little clearer with what you want? In the current qpid
implementation (in C++ broker at least) durability of messages isn't
related to the transport (which is a networking concept), but to a
persistence
On 02/08/2011 10:30 AM, Robbie Gemmell wrote:
For example, this commit should have had a JIRA, and the commit it
reverts had a JIRA listed. However, looking at the commit tab on that
JIRA in future there will be no indication this revert occured.
URL:
I'm interested in the classic durable subscription case - two clients and a
broker, client 2 has a durable subscription to a queue, client 1 sends
something to that queue while client 2 is disconnected. When client 2
reconnects it would like to receive the messages it missed. Ideally this
could
[
https://issues.apache.org/jira/browse/QPID-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992086#comment-12992086
]
Rajith Attapattu commented on QPID-2994:
We do throw an exception indicating that
[
https://issues.apache.org/jira/browse/QPID-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated QPID-3045:
--
Description:
See https://bugzilla.redhat.com/show_bug.cgi?id=675921
was:See
On 02/07/2011 11:55 PM, Andrew Kennedy wrote:
Perhaps we should designate a package (or more?) which will only contain
public interfaces.
That sounds like a good idea to me.
Probably org.apache.qpid.jms is the right place for
these?
I agree in principle, though some of the classes or
[
https://issues.apache.org/jira/browse/QPID-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway resolved QPID-3045.
---
Resolution: Fixed
Fixed in r1068554
QPID-3045 - sporadic failure of
QMFv2 Completion and Cleanup
Key: QPID-3046
URL: https://issues.apache.org/jira/browse/QPID-3046
Project: Qpid
Issue Type: New Feature
Components: Qpid Managment Framework
Reporter: Ted
[
https://issues.apache.org/jira/browse/QPID-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992264#comment-12992264
]
Ted Ross commented on QPID-3046:
There has been discussion about moving the QMF code out of
30 matches
Mail list logo
