Hide Forgot
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.
The same issue is present for queue tests
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
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
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
https://issues.apache.org/jira/browse/QPID-3838
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.
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
Rajith, please provide release not content in the technical notes field.
A fix has been committed upstream http://svn.apache.org/r1480656 When running the TCK please use -Dstrict-jms=true
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
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
Created attachment 795837 [details] TCK tests run with -Dstrict-jms=true
Can we please re test the TCK with the new client?