You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "Krzysztof Porebski (Jira)" <ji...@apache.org> on 2019/10/03 10:00:20 UTC

[jira] [Updated] (AMQNET-612) ObjectMessage shouldn't have jms-msg-type set

     [ https://issues.apache.org/jira/browse/AMQNET-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Krzysztof Porebski updated AMQNET-612:
--------------------------------------
    Component/s:     (was: NMS)

> ObjectMessage shouldn't have jms-msg-type set
> ---------------------------------------------
>
>                 Key: AMQNET-612
>                 URL: https://issues.apache.org/jira/browse/AMQNET-612
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: AMQP
>    Affects Versions: 1.8.0
>            Reporter: Krzysztof Porebski
>            Priority: Major
>              Labels: nms-amqp
>             Fix For: 1.8.0
>
>          Time Spent: 8h 10m
>  Remaining Estimate: 0h
>
> 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 ??



--
This message was sent by Atlassian Jira
(v8.3.4#803005)