[jira] [Commented] (QPID-3025) Upgrade Java test framework to JUnit 4

2013-01-07 Thread Philip Harvey (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13546646#comment-13546646
 ] 

Philip Harvey commented on QPID-3025:
-

I've paused this upgrade while the config refactoring work is in progress on 
the config refactoring branch for QPID-4390 
(https://svn.apache.org/repos/asf/qpid/branches/java-broker-config-qpid-4390/).

I looked into how we could use JUnit 4's Categories runner to replace our test 
filtering logic, but have run into problems. In case anyone's interested, here 
is a summary:

The vanilla usage of the org.junit.experimental.categories.Categories runner is 
to write a dedicated suite like so:
{noformat}
@RunWith(Categories.class)
@IncludeCategory(SlowTests.class)
@SuiteClasses( { A.class, B.class })
// Note that Categories is a kind of Suite
public static class SlowTestSuite {
}
{noformat}

It's obviously undesireable to enumerate all the test classes. The most common 
way round this is to use the ClasspathSuite library 
(http://johanneslink.net/projects/cpsuite.jsp), as described on Stack Overflow 
[here|http://stackoverflow.com/questions/2176570/how-to-run-all-tests-belonging-to-a-certain-category-in-junit-4/2176791#2176791]

Unfortunately ClasspathSuite is GPL 2.0 licensed, so cannot be used by Qpid.

The only alternative therefore seems to be that we write our own ClassPathSuite 
equivalent, i.e. something that searches the classpath for all the classes with 
@Test annotations. This is not particularly hard but it is frustrating that we 
need reinvent the wheel in this manner. A good starting point is the example 
code 
[here|http://linsolas.free.fr/wordpress/index.php/2011/02/how-to-categorize-junit-tests-with-maven/].

> Upgrade Java test framework to JUnit 4
> --
>
> Key: QPID-3025
> URL: https://issues.apache.org/jira/browse/QPID-3025
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Tests
>Reporter: Andrew Kennedy
>Assignee: Philip Harvey
>Priority: Minor
> Attachments: 0001-QPID-3025-WIP-junit4-upgrade.patch
>
>
> We use JUnit 3.8 currently, and should move to using a more recent version. 
> JUnit 4.4 includes support for annotations and other useful test features 
> that will allow us to control our unit and system tests and test profiles 
> better and easier. This update must still be able to run the existing 3.8 
> tests, and must also preserve the current exclusion mechanism 
> (profile.excludes property) but should also support all JUnit 4 features. 
> This is possible by transferring some functionality from QpidTestCase to a 
> custom JUnit runner class, and annotating QpidTestCase to use this new test 
> runner.
> See also QPID-2639 which updated the QpidTestCase and modified all other test 
> cases to inherit from it.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



Re: 0.20 release update - RC3 is out, C++ and proton problem

2013-01-07 Thread Justin Ross
Hi, Keith.  This one is big enough that I want to double check.  Is this 
still a good change for 0.20?  (For example, have subsequent CI runs on 
trunk been clean?)  Also, is it a regression?


Thanks,
Justin

On Thu, 27 Dec 2012, Keith W wrote:


Hi Justin,

Can I request the inclusion of QPID-4503 in 0.20?  It is a small
changs in a narrow area of code to address a race condition in a
feature to detect producer transaction timeouts.

http://svn.apache.org/viewvc?view=revision&revision=1421884
http://svn.apache.org/viewvc?view=revision&revision=1424427

Kind regards, Keith.



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (QPID-4521) [Java broker] routing to an alternate exchange during queue deletion and AMQP 0-10 message-reject fails when it is a topic exchange

2013-01-07 Thread Justin Ross (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-4521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13546215#comment-13546215
 ] 

Justin Ross commented on QPID-4521:
---

Reviewed by Keith.  Approved for 0.20.

> [Java broker] routing to an alternate exchange during queue deletion and AMQP 
> 0-10 message-reject fails when it is a topic exchange
> ---
>
> Key: QPID-4521
> URL: https://issues.apache.org/jira/browse/QPID-4521
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.16, 0.18, 0.20
>Reporter: Robbie Gemmell
>Assignee: Keith Wall
>Priority: Minor
> Fix For: 0.21
>
>
> Routing to an alternate exchange during queue deletion fails for topic 
> exchanges. This is because the InboundMessageAdapter used to adapt the queues 
> QueueEntry for routing by the exchange has a defect in the 
> getRountingKeyShortSring() method. This method returns an AMQShortString and 
> is used by the Topic exchange (to avoid redoing much of the Topic matching 
> logic that uses AMQShortString) whereas the other exchanges use the 
> getRoutingKey() method which returns a String.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (QPID-4519) [Java broker] Virtualhost JMX MBean StatusEnabled attribute has the wrong value, and checking it should not cause an update

2013-01-07 Thread Justin Ross (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-4519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13546214#comment-13546214
 ] 

Justin Ross commented on QPID-4519:
---

Reviewed by Alex.  Approved for 0.20.

> [Java broker] Virtualhost JMX MBean StatusEnabled attribute has the wrong 
> value, and checking it should not cause an update
> ---
>
> Key: QPID-4519
> URL: https://issues.apache.org/jira/browse/QPID-4519
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.18, 0.20
>Reporter: Robbie Gemmell
>Assignee: Alex Rudyy
> Fix For: 0.21
>
>
> The VirtualHost JMX MBean is currently returning false for isStatusEnabled; 
> it should be true as the feature is now always enabled (the attribute was 
> only maintained for compatibility). More of an issue however is that checking 
> the value prompts a stats update to occur, which it should not.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Commented] (QPID-4512) [Java Broker] JMX QueueMBean#deleteMessages only deletes the first matching message from the range

2013-01-07 Thread Justin Ross (JIRA)

[ 
https://issues.apache.org/jira/browse/QPID-4512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13546213#comment-13546213
 ] 

Justin Ross commented on QPID-4512:
---

Reviewed by Alex.  Approved for 0.20.

> [Java Broker] JMX QueueMBean#deleteMessages only deletes the first matching 
> message from the range
> --
>
> Key: QPID-4512
> URL: https://issues.apache.org/jira/browse/QPID-4512
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.18, 0.20
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: 0.21
>
>
> Upon trying to delete the range of messages from the queue using JMX Queue 
> MBean deleteMessages operation, only the first matching message from the 
> range is deleted and the rest is simply ignored.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Resolved] (QPID-3569) Refactor TransactionTimeout

2013-01-07 Thread Keith Wall (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPID-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall resolved QPID-3569.
--

   Resolution: Fixed
Fix Version/s: 0.21

> Refactor TransactionTimeout
> ---
>
> Key: QPID-3569
> URL: https://issues.apache.org/jira/browse/QPID-3569
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: 0.21
>
> Attachments: 0001-QPID-3569-Refactor-TransactionTimeout.patch, 
> 0001-QPID-3569-Refactor-TransactionTimeout.patch, 
> 0001-QPID-3569-Refactor-TransactionTimeout.patch, 
> 0001-QPID-3569-Refactor-TransactionTimeout.patch
>
>
> The Transaction Timeout feature of the Java Broker relies heavily on system 
> tests.  It would be better if its implementation were refactored to allow 
> more of its functionality to be tested by unit tests and a reduced number of 
> system tests. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



[jira] [Updated] (QPID-3569) Refactor TransactionTimeout

2013-01-07 Thread Keith Wall (JIRA)

 [ 
https://issues.apache.org/jira/browse/QPID-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall updated QPID-3569:
-

Status: Ready To Review  (was: In Progress)

> Refactor TransactionTimeout
> ---
>
> Key: QPID-3569
> URL: https://issues.apache.org/jira/browse/QPID-3569
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Attachments: 0001-QPID-3569-Refactor-TransactionTimeout.patch, 
> 0001-QPID-3569-Refactor-TransactionTimeout.patch, 
> 0001-QPID-3569-Refactor-TransactionTimeout.patch, 
> 0001-QPID-3569-Refactor-TransactionTimeout.patch
>
>
> The Transaction Timeout feature of the Java Broker relies heavily on system 
> tests.  It would be better if its implementation were refactored to allow 
> more of its functionality to be tested by unit tests and a reduced number of 
> system tests. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org



Review Request: Prevent duplicate binding keys on headers exchanges

2013-01-07 Thread Kenneth Giusti

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8862/
---

Review request for qpid, Gordon Sim and Ted Ross.


Description
---

First off - this patch does _not_ fix the federation bugs involving headers 
exchanges.  So it's not a fix for qpid-3356.  But it does address one issue 
pointed out by Gordon in qpid-3356: the headers exchange did not correctly 
preserve the uniqueness of exchange+queue+key as a mgmt index to bindings.

This patch addresses that aspect of qpid-3356 by tracking the exchange's 
current bindings a bit better, and preventing the configuration of duplicate 
bindings regardless of the associated argument values.


This addresses bug qpid-3356.
https://issues.apache.org/jira/browse/qpid-3356


Diffs
-

  /trunk/qpid/cpp/src/qpid/broker/HeadersExchange.h 1428944 
  /trunk/qpid/cpp/src/qpid/broker/HeadersExchange.cpp 1428944 
  /trunk/qpid/cpp/src/tests/ExchangeTest.cpp 1428944 
  /trunk/qpid/cpp/src/tests/federation.py 1428944 

Diff: https://reviews.apache.org/r/8862/diff/


Testing
---

unit tests updated.


Thanks,

Kenneth Giusti