Major Description
From the mailing list:
"I was having a look at the readme, which then lead to me having a poke
around the repo for the ObjectMessage handling based on something I
read. I think there may be an issue in the object message handling and
would propose a change if its actually doing what some of the code
suggests. I could be entirely wrong here though, I havent run it up to
be sure as I dont have the environment or clue to do so, so thought
I'd mention this here for now rather than e.g a JIRA.
It appeared that the client will always set the x-opt-jms-msg-type
annotation on messages, presumably with aim of increased
interoperability with receiving JMS AMQP clients, which is generally
fine (though the JMS client handles most cases without that through
other means). However in the case of object messages it appeared like
it might do so in a way that will specifically prevent interop at all
by default. It looked like it will send a Data section with serialized
object content and a "application/x-dotnet-serialized-object" content
type, which all seems fine and expected, but it also looked like it
will still set the x-opt-jms-msg-type value set for a JMS
ObjectMessage type at the same time. It doesnt feel like that should
be the case here, given the payload is known to be incompatible and
the JMS client wont be able to return such content to an application.
Omitting the annotation when sending such serialized dotnet message
payload would allow it to be treated as a BytesMessage on a receiving
JMS client (due to the unknown content type) and then at least the
application could retrieve the raw payload and do what it likes with
it." Robbie Gemmell
Attachments
Issue Links
- links to
