JMS TCK status

[gaohoward]

I'm creating this thread to report and discuss JMS TCK test issues:

* com/sun/ts/tests/jms/core20/jmsproducerqueuetests/Client.java#msgPropertiesTest_from_appclient
This test fails at line com.sun.ts.tests.jms.core20.jmsproducerqueuetests.Client.msgPropertiesTest(Client.java:2971)

            try {
                byte    value = producer.getByteProperty("TESTDUMMY");
                logMsg("Fail: NumberFormatException should have occurred for getByteProperty");
                pass = false;
            } catch (java.lang.NumberFormatException np) {
                logMsg("Pass: NumberFormatException as expected ");
            }

It expects a NumberFormatException but HornetQ throws a JMSRuntimeException. Checking out the JMS2.0 API doc, I found
the JMSProducer.getByteProperty() throws two type of exceptions:

JMSRuntimeException
MessageFormatRuntimeException

Which means HornetQ's behavoir is legitimate, and the test are not.

What should we do?

[clebert.suconic]

Did you update your branch? I fixed that one already AFAIK

[gaohoward]

Just checked my branch, I've 2 commits behind the upstream:

commit abb8f5a1bc96cbeaaae65396355673b57fbd0c1c

Merge: 520fad5 66114f2

Author: clebertsuconic <[e-mail]>

Date:   Wed Jul 24 04:24:36 2013 -0700

    Merge pull request #1178 from andytaylor/master

    use ra connection factory from RA when connectionfactoryLookup is set

commit 66114f2d8d5d17b01761d602a313d6af9ce8a390

Author: Andy Taylor <[e-mail]>

Date:   Wed Jul 24 10:08:30 2013 +0100

    use ra connection factory from RA when connectionfactoryLookup is set

But they don't seem to be relevant to this test.

[clebert.suconic]

You're right.. I confused with another byteTest... sorry about that... I coudln't answer before today as I was stuck on a meeting...

Anyway... make the test to throw MessageFormatException on that case and I will raise an issue with the Spec Group.... we will probably add this test to the ignore list or have Oracle fixing it.. (It seems an easy fix to the test).

[clebert.suconic]

Howard, the test is correct. The spec lead refreshed my memory and provided me an answer:

Look at:

http://jms-spec.java.net/2.0/apidocs/javax/jms/Message.html#getByteProperty%28java.lang.String%29

"

Getting a property value for a name which has not been set returns a null value. Only the getStringProperty and getObjectProperty methods can return a null value. Attempting to read a null value as a primitive type must be treated as calling the primitive's corresponding valueOf(String) conversion method with a null value."

We will have to do the same conversion done on Message.getByteProperty.. going through some valueOf and that would throw the Exception.

[gaohoward]

ok, understood. Thanks.

[gaohoward]

* com/sun/ts/tests/jms/core/topictests/TopicTests.java#consumerTests_from_ejb

Investigated this test failure, I found when a CF is configured with a client-id, each connection created from it will have the same client-id. That seems against the spec as each connection should have a unique id. If we use Connection.setClientID(String id) then HornetQ can guarantee the id is server-wise unique (see ServerSessionImpl.addUniqueMetaData()).

In this test if you print out the client id of the two connections it uses, they both have the same id 'cts7'. And in the test a message is sent via a connection and expect it is received by a noLocalConsumer via the other connection. Because of both connection has same client-id, the message won't get received.

[clebert.suconic]

I have written a script to replace hornetq on wildfly. I have no checks whatsoever (like throwing an error or something), but the scripts works nicely. No more need to rebuild the whole thing to replace jboss-client.jar what has helped me on debugging and fixing.