Bug 782403

Summary: TCK: Presence of JMS header qpid.subject JMS breaks TCK tests
Product: Red Hat Enterprise MRG Reporter: Jiri Pechanec <jpechane>
Component: qpid-javaAssignee: messaging-bugs <messaging-bugs>
Status: NEW --- QA Contact: Messaging QE <messaging-qe-bugs>
Severity: high Docs Contact:
Priority: medium    
Version: DevelopmentCC: iboverma, jpechane, jross, mtoth
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qpid-jca-0.22-1 Doc Type: Bug Fix
Doc Text:
Cause: Qpid doesn't prefix vendor properties with "JMS_". Consequence: This causes a TCK failure as the tests use JMS_ to filter out properties. Fix: We now prefix "qpid,subject" with "JMS_" if -Dstrict-jms=true is used. Result: The test that rely on "JMS_" for filtering should pass.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Patch for renaming the property name when strict-jms mode is used
none
TCK tests run with -Dstrict-jms=true none

Description Jiri Pechanec 2012-01-17 11:52:25 UTC
The TCK test execution was moved from using BURL to ADDR addressing scheme because with upgrade to 0.14 it was no longer maintainable.

Unfortunately after this change the messages that comes through topic have set a JMS header 'qpid.subject'. Albeit it is not forbidden to have custom headers set the issue is TCK asserts exact number and exact names of headers it expects.
Thus the unexpected header breaks all topic properties related tests.

Comment 1 Jiri Pechanec 2012-01-17 15:01:40 UTC
The same issue is present for queue tests

Comment 2 Rajith Attapattu 2012-01-19 14:59:28 UTC
Jiri,

IMO the test is very very narrow here. The JMS spec does not preclude custom headers at all. 

We shouldn't be doing work arounds in the code to just pass a poorly written TCK test.

Regards,

Rajith

Comment 3 Rajith Attapattu 2012-01-26 20:16:48 UTC
As discussed on email we will add a special JVM argument to ensure we convert (when creating the JMS message from an AMQP message) qpid.subject to JMS_qpid.subject

However this will be done once I've got through the other high priority items.

Rajith

Comment 4 Jiri Pechanec 2012-02-03 10:05:28 UTC
Tests affected
com/sun/ts/tests/jms/ee/all/topicproperty/TopicPropertyTests.java#msgPropertiesTopicTest_from_appclient
com/sun/ts/tests/jms/ee/all/topicproperty/TopicPropertyTests.java#msgPropertiesTopicTest_from_ejb
com/sun/ts/tests/jms/ee/all/topicproperty/TopicPropertyTests.java#msgPropertiesTopicTest_from_jsp
com/sun/ts/tests/jms/ee/all/topicproperty/TopicPropertyTests.java#msgPropertiesTopicTest_from_servlet
com/sun/ts/tests/jms/ee/mdb/mdb_msgPropsT/MDBClient.java#mdbMsgPropertiesTTest

Comment 5 Justin Ross 2012-02-14 19:28:11 UTC
https://issues.apache.org/jira/browse/QPID-3838

Comment 6 Rajith Attapattu 2012-02-14 21:39:13 UTC
Created attachment 562048 [details]
Patch for renaming the property name when strict-jms mode is used

If -Dstrict-jms=true is specified as a jvm argument, the client will rename "qpid.subject" to "JMS_qpid.subject".

However when retrieving the subject, "qpid.subject" will still work (even when running in strict-jms mode) for compatibility reasons.

Comment 7 Rajith Attapattu 2012-02-14 21:56:53 UTC
Turning on strict-jms will make the client throw an exception when it sees the x-jms-type property used internally to denote the message type. This unexpected exception will cause several test failures.

Working around that is more hassle than worth it.
Another option is to use a different jvm arg, but that sounds quite cheesy :D

IMHO, it's best to not worry about this issue for this release.

Rajith

Comment 8 Justin Ross 2012-02-16 15:24:34 UTC
Rajith, please provide release not content in the technical notes field.

Comment 10 Rajith Attapattu 2013-05-09 14:26:32 UTC
A fix has been committed upstream  http://svn.apache.org/r1480656

When running the TCK please use -Dstrict-jms=true

Comment 12 Jiri Pechanec 2013-08-20 06:32:21 UTC
I came to the issue when we run TCK tests as an effort to certify MRG with EAP. 
Setup - EAP with JCA adapter configured to communicate with a MRG-M server. JMS TCK executed against the configured EAP server

Comment 17 Valiantsina Hubeika 2013-08-29 20:18:50 UTC
tests were run with -Dstrict-jms=true and the following was observed with tests addressed in Comment 4:

tests that pass:
com/sun/ts/tests/jms/ee/all/topicproperty/TopicPropertyTests.java#msgPropertiesTopicTest_from_ejb
com/sun/ts/tests/jms/ee/all/topicproperty/TopicPropertyTests.java#msgPropertiesTopicTest_from_jsp
com/sun/ts/tests/jms/ee/all/topicproperty/TopicPropertyTests.java#msgPropertiesTopicTest_from_servlet

tests that still fail :
com/sun/ts/tests/jms/ee/all/topicproperty/TopicPropertyTests.java#msgPropertiesTopicTest_from_appclient

com/sun/ts/tests/jms/ee/mdb/mdb_msgPropsT
/MDBClient.java#mdbMsgPropertiesTTest

Comment 20 Valiantsina Hubeika 2013-09-10 06:15:18 UTC
Created attachment 795837 [details]
TCK tests run with -Dstrict-jms=true

Comment 22 Rajith Attapattu 2013-10-01 15:29:12 UTC
Can we please re test the TCK with the new client?