|
As of October 27th, please open all new issues in the Red Hat Customer Portal . |
|
[
Permlink
| « Hide
]
Willem Jiang added a comment - 12/Jun/12 08:13 AM
This issue is related the jaxws-api 2.2 spec api bundle.
Added @Ignore to two more failing tests.
org.apache.cxf.systest.ws.rm.ProtocolVariationsTest.testDefaultDecoupled Both are failing on Hudson with : Unexpected number of inbound messages [0] Latest build is green http://ci.fusesource.com/hudson/view/Camel/job/camel-2.9.0.fuse-7-0-x-stable-checkin/1/
The following tests still contain @Ignore and fail if you remove them. The rest are fixed
components/camel-jms/src/test/java/org/apache/camel/component/jms/tx/JmsToJmsTransactedSecurityTest.java JmsToJmsTransactedSecurityTest is failed with ActiveMQ 5.5.1.fuse-7-061, but the test passed with ActiveMQ 5.5.1.
When the queue authorization failed the ActiveMQ 5.5.1 will put the message into the ActiveMQ.DLQ, but ActiveMQ 5.5.1.fuse-7-061 doesn't put the message into ActiveMQ.DLQ. We need ask the help for ActiveMQ engineer to fix this test. NOTE: I just test the ActiveMQ 5.5.1.fuse-07-72, I still got the same error. I managed to fix other osgi related test failures by starting the bundle by default and will commit the fix shortly.
peeking into JmsToJmsTransactedSecurityTest to see if I can find the amq root cause for the change and validate it.
The problem is the change of behavior w.r.t a security exception that was introduced with the fix fo https://issues.apache.org/jira/browse/AMQ-3294
The activemq connection now does a teardown/dispose when a SecurityException is returned from the broker an this means that the rollback fails with a 'connection disposed exception'. So the question is this:
is the JmsToJmsTransactedSecurityTest a valid use case? Or can we just drop the expectation that the transaction will rollback on the exception and redelivery failure and send to DQL occurs. Currently the rollback fails so there is no redelivery redelivery. I answered my own question, I think the use case is reasonable and amq is being too draconian. It makes sense to whack the connection on a security exception on initial connect, but not once the connection is validated/authenticated.
I amended https://issues.apache.org/jira/browse/AMQ-3294 Fix is on 5.5.1-fuse branch. Guess it will make 7.1 but not 7.0.1 at this stage. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||