Effective October 27, 2012, online and email support for FuseSource products will move to Red Hat support channels. For more information, please see the JIRA Migration to Red Hat FAQ.
As of October 27th, please open all new issues in the Red Hat Customer Portal .
Issue Details (XML | Word | Printable)

Key: ENTESB-185
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Willem Jiang
Reporter: Kevin Earls
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Fuse ESB Enterprise

camel-2.9.x-fuse-checkin build has 15 unit test failures

Created: 01/Jun/12 07:59 PM   Updated: 30/Nov/12 12:29 PM
Component/s: None
Affects Version/s: None
Fix Version/s: 7.1.0

Environment: Hudson
Issue Links:
Linked


 Description  « Hide
The following tests are failing in the camel-2.9.x-fuse-checkin on Hudson

org.apache.camel.component.jms.tx.JmsToJmsTransactedSecurityTest.testJmsSecurityFailure
org.apache.camel.itest.osgi.cxf.CxfBeanSpringRouteTest.testGetCustomer
org.apache.camel.itest.osgi.cxf.CxfProxyExampleTest.testCxfProxy
org.apache.camel.itest.osgi.cxf.blueprint.CxfBeanBlueprintRouterTest.testGetCustomer
org.apache.camel.itest.osgi.cxf.blueprint.CxfBeanBlueprintRouterTest.testGetCustomerWithQuery
org.apache.camel.itest.osgi.cxf.blueprint.CxfBlueprintRouterTest.testRouter
org.apache.camel.itest.osgi.cxf.blueprint.CxfRsBlueprintRouterTest.testGetCustomer
org.apache.camel.itest.osgi.cxf.blueprint.CxfRsBlueprintRouterTest.testGetCustomerWithQuery
org.apache.camel.itest.osgi.cxf.blueprint.CxfRsBlueprintRouterTest.testGetCustomers
org.apache.camel.itest.osgi.cxf.blueprint.CxfRsBlueprintRouterTest.testGetSubResource
org.apache.camel.itest.osgi.cxf.blueprint.CxfRsBlueprintRouterTest.testPutConsumer
org.apache.camel.itest.osgi.cxf.blueprint.CxfRsBlueprintRouterTest.testPostConsumer
org.apache.camel.itest.osgi.hdfs.HdfsBlueprintRouteTest.testWriteAndReadString [felix]
org.apache.camel.itest.osgi.hdfs.HdfsRouteTest.testReadString
org.apache.camel.itest.osgi.jpa.JpaBlueprintRouteTest.testBlueprintRouteJpa

I have added @Ignore annotations to the failing tests in these files:

components/camel-jms/src/test/java/org/apache/camel/component/jms/tx/JmsToJmsTransactedSecurityTest.java
tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/cxf/CxfBeanSpringRouteTest.java
tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/cxf/CxfProxyExampleTest.java
tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/cxf/blueprint/CxfBeanBlueprintRouterTest.java
tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/cxf/blueprint/CxfBlueprintRouterTest.java
tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/cxf/blueprint/CxfRsBlueprintRouterTest.java
tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/hdfs/HdfsBlueprintRouteTest.java
tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/hdfs/HdfsRouteTest.java
tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/jpa/JpaBlueprintRouteTest.java



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Willem Jiang added a comment - 12/Jun/12 08:13 AM
This issue is related the jaxws-api 2.2 spec api bundle.

Kevin Earls added a comment - 12/Jun/12 12:20 PM
Added @Ignore to two more failing tests.

org.apache.cxf.systest.ws.rm.ProtocolVariationsTest.testDefaultDecoupled
org.apache.cxf.systest.ws.rm.ProtocolVariationsTest.testRM10WSA200408Decoupled

Both are failing on Hudson with : Unexpected number of inbound messages [0]


Willem Jiang added a comment - 26/Jun/12 08:47 AM
Now those tests are passed.

Jonathan Anstey added a comment - 19/Jul/12 06:39 PM
Latest build is green http://ci.fusesource.com/hudson/view/Camel/job/camel-2.9.0.fuse-7-0-x-stable-checkin/1/ . Do we have anymore tests to fix for this issue or is it OK to close?

Kevin Earls added a comment - 19/Jul/12 07:49 PM
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
tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/cxf/blueprint/CxfBeanBlueprintRouterTest.java
tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/cxf/blueprint/CxfRsBlueprintRouterTest.java
tests/camel-itest-osgi/src/test/java/org/apache/camel/itest/osgi/jpa/JpaBlueprintRouteTest.java


Willem Jiang added a comment - 20/Jul/12 07:35 AM - edited
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.


Willem Jiang added a comment - 20/Jul/12 08:35 AM
I managed to fix other osgi related test failures by starting the bundle by default and will commit the fix shortly.

Gary Tully added a comment - 20/Jul/12 09:40 AM
peeking into JmsToJmsTransactedSecurityTest to see if I can find the amq root cause for the change and validate it.

Gary Tully added a comment - 26/Jul/12 02:47 PM
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'.


Gary Tully added a comment - 26/Jul/12 03:11 PM
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.

Gary Tully added a comment - 31/Jul/12 02:12 PM
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 to sort that out.
Fix is on 5.5.1-fuse branch. Guess it will make 7.1 but not 7.0.1 at this stage.