Clebert,
On 25/07/2013 00:26, Clebert Suconic wrote:
> Accordingly to the Javadoc, getByteProperty("name") was supposed to throw two exceptions (i), However the test is
> asserting for a different exception. It seems a mistake on the test to me. How should we raise issues on the TCK?
>
>
> (i):
> Throws:
>
> |JMSRuntimeException <file:///Users/clebertsuconic/Desktop/JMS2/jms-2/javax/jms/JMSRuntimeException.html>| - if
> the JMS provider fails to get the property value due to some internal error.
> |MessageFormatRuntimeException
> <file:///Users/clebertsuconic/Desktop/JMS2/jms-2/javax/jms/MessageFormatRuntimeException.html>| - if this type
> conversion is invalid.
>
> (ii):
> 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 ");
> }
>
The formal answer to your question is that you should raise issues with the TCK to the Oracle Java Partner Engineering
team from whom you obtained the TCK. But I'm happy to forward queries.
In this case I think the test is correct. This test relates to JMSProducer#getByteProperty
http://jms-spec.java.net/2.0/apidocs/javax/jms/JMSProducer.html#getByteProperty%28java.lang.String%29
The methods on JMSProducer to set and get message properties are provided as a convenient way to set and get properties
of the Message object that will be sent. For this reason the methods on JMSProducer are deliberate copies of the
corresponding methods on Message, with the same method names, parameters and return types (apart from in one case). The
exceptions thrown are the same, though in line with the rest of the simplified API, JMSRuntimeException and its subtypes
are used instead of JMSException.
I therefore think we need to refer to the corresponding method on Message,
http://jms-spec.java.net/2.0/apidocs/javax/jms/Message.html#getByteProperty%28java.lang.String%29
The exceptions this defines for Message.getByteProperty are identical to those on JMSProducer#getByteProperty apart from
the use of checked rather than unchecked exceptions.
However this isn't the complete definition of the exceptions that are thrown by Message.getByteProperty. The API doc for
the Message object also states (in a long section discussing the conversion of message properties between different types):
/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./
For this reason, calling Message#getByteProperty for a name which has not been set throws the same exception as
Byte.valueOf((String)null).byteValue();
Which is a java.lang.NumberFormatException. There is a JMS 1.1 TCK test which ensures this.
Now I'm aware that the API docs for JMSProducer don't explicitly state that the rules for converting message properties
between different types are the same on JMSProducer as for Message, but that's definitely the intent, for that that
reason I think that calling JMSProducer#getByteProperty for a name which has not been set, thereby generating a null
property which cannot be converted, should throw the same exception.
Nigel