7 Replies Latest reply on Jul 31, 2013 6:43 PM by Clebert Suconic

    JMS TCK status

    Yong Hao Gao Master

      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?

        • 1. Re: JMS TCK status
          Clebert Suconic Master

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

          • 2. Re: JMS TCK status
            Yong Hao Gao Master

            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 Master

              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 Master

                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.

                1 of 1 people found this helpful
                • 5. Re: JMS TCK status
                  Yong Hao Gao Master

                  ok, understood. Thanks.

                  • 6. Re: JMS TCK status
                    Yong Hao Gao Master

                    * 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 Master

                      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.