You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@activemq.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2019/09/13 19:29:00 UTC

[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16929472#comment-16929472 ] 

ASF subversion and git services commented on AMQNET-612:
--------------------------------------------------------

Commit 3e0f0baf2f3952c7d5037c6b66a1d49b1f4a6848 in activemq-nms-amqp's branch refs/heads/master from Havret
[ https://gitbox.apache.org/repos/asf?p=activemq-nms-amqp.git;h=3e0f0ba ]

AMQNET-612: ObjectMessage shouldn't have jms-msg-type set


> 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, NMS
>    Affects Versions: 1.8.0
>            Reporter: Krzysztof Porebski
>            Priority: Major
>          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.2#803003)