-
1. Re: JMS TCK status
clebert.suconic Jul 24, 2013 11:37 AM (in response to gaohoward)Did you update your branch? I fixed that one already AFAIK
-
2. Re: JMS TCK status
gaohoward Jul 24, 2013 11:46 AM (in response to clebert.suconic)Just checked my branch, I've 2 commits behind the upstream:
commit abb8f5a1bc96cbeaaae65396355673b57fbd0c1c
Merge: 520fad5 66114f2
Author: clebertsuconic <clebert.suconic@gmail.com>
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 <ataylor@redhat.com>
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.
-
3. Re: JMS TCK status
clebert.suconic Jul 24, 2013 7:28 PM (in response to gaohoward)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).
-
4. Re: JMS TCK status
clebert.suconic Jul 25, 2013 6:24 AM (in response to clebert.suconic)1 of 1 people found this helpfulHoward, 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
andgetObjectProperty
methods can return a null value. Attempting to read a null value as a primitive type must be treated as calling the primitive's correspondingvalueOf(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.
-
5. Re: JMS TCK status
gaohoward Jul 25, 2013 7:50 AM (in response to clebert.suconic)ok, understood. Thanks.
-
6. Re: JMS TCK status
gaohoward Jul 25, 2013 12:12 PM (in response to 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.
-
7. Re: JMS TCK status
clebert.suconic Jul 31, 2013 6:43 PM (in response to gaohoward)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.