[
https://issues.apache.org/jira/browse/AMQNET-612?focusedWorklogId=311724&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-311724
]
ASF GitHub Bot logged work on AMQNET-612:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 12/Sep/19 21:01
Start Date: 12/Sep/19 21:01
Worklog Time Spent: 10m
Work Description: Havret commented on issue #31: AMQNET-612:
ObjectMessage shouldn't have jms-msg-type set
URL: https://github.com/apache/activemq-nms-amqp/pull/31#issuecomment-531004899
I believe we can have our own content type, but we cannot use it alongside
with `x-opt-jms-msg-type`. @gemme
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 311724)
Time Spent: 6h 20m (was: 6h 10m)
> 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: 6h 20m
> 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)
