Oh... I see.. now I remember that part... sorry for the mess up.. I forgot
about the valueOf...
Thanks a lot
On Thu, Jul 25, 2013 at 10:51 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> 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 - if the JMS provider fails to get the property
> value due to some internal error. MessageFormatRuntimeException - 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
>
>
>
--
Clebert Suconic
http://community.jboss.org/people/clebert.suconic@jboss.com
http://clebertsuconic.blogspot.com