[
https://issues.apache.org/jira/browse/QPID-6404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14330209#comment-14330209
]
Robbie Gemmell commented on QPID-6404:
--------------------------------------
{quote}
A message without any form of body is not valid according to the spec. (Yes
this did surprise me when I first read it... and yes I am one of the authors of
the spec )
{quote}
I've brought this up a number of times, and both you and Rafi said thats not
what you all meant and seemed to think I was being a bit pedantic ;) The JMS
Mapping doc and the new client code are currently litterred with TODOs to make
it more discoverable where they take advantage of not sending bodies or
describe what to do when not receiving any as a result.
Changing the client to always send bodies seems fine to me to stop exceptions
like the above. However, it looks like the same exception will now happen when
receiving such messages, which I dont think is a great idea given essentially
everything out there currently allows sending and receiving them. Could the
newly introduced validation be relaxed for received messages such that only the
order of the sections present is enforced?
Back to the actual change, I'd guess that means the client would receive those
messages as a BytesMessage rather than the 'bare Message' that it sends them
as, which might catch some folks out? Probably not a big deal, folks sending
Message shouldnt really be checking the type on receipt hehe. The JMS Mapping
doc currently suggests using an AmqpValue encoded null for Message (if you send
anything, that is ;)). It also relies on the message type annotation on reciept
to figure out it is 'only' a Message, as a non-annotated amqp-value+null is
treated as a TextMessage with the default null String, which is what both the
JMS clients send.
> [AMQP 1.0 JMS Client ] Cannot send simple empty body JMS Message types
> ----------------------------------------------------------------------
>
> Key: QPID-6404
> URL: https://issues.apache.org/jira/browse/QPID-6404
> Project: Qpid
> Issue Type: Bug
> Components: JMS AMQP 1.0 Client
> Affects Versions: 0.31
> Reporter: Timothy Bish
> Assignee: Rob Godfrey
> Attachments: reproducer.tar.bz2
>
>
> Test ActiveMQ against 0.32-SNAPSHOT I see lots of test failures around
> sending of the simple JMS Message object (no body).
> Error logged during test:
> {noformat}
> java.lang.IllegalArgumentException: Message must contain one of Data,
> AmqpValue or AmqpSequence
> at
> org.apache.qpid.amqp_1_0.client.Message.reorderSections(Message.java:168)
> at
> org.apache.qpid.amqp_1_0.client.Message.validateOrReorder(Message.java:147)
> at org.apache.qpid.amqp_1_0.client.Message.<init>(Message.java:120)
> at
> org.apache.qpid.amqp_1_0.jms.impl.MessageProducerImpl.send(MessageProducerImpl.java:307)
> at
> org.apache.qpid.amqp_1_0.jms.impl.MessageProducerImpl.send(MessageProducerImpl.java:240)
> at
> org.objectweb.jtests.jms.conform.connection.ConnectionTest.testAcknowledge(ConnectionTest.java:58)
> {noformat}
> I'll attach a simple reproducer that shows the problem, it spins up an
> ActiveMQ Broker and sends one message to demonstrate the error.
> I only poked at the history a little but my guess would be changes for
> QPID-6338 might be the culprit given it touches the area in question.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
