Uploaded image for project: 'ActiveMQ .Net'
  1. ActiveMQ .Net
  2. AMQNET-612

ObjectMessage shouldn't have jms-msg-type set



    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 1.8.0
    • 1.8.0
    • AMQP


      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 


        Issue Links



              Unassigned Unassigned
              havret Krzysztof Porębski
              0 Vote for this issue
              2 Start watching this issue



                Time Tracking

                  Original Estimate - Not Specified
                  Not Specified
                  Remaining Estimate - 0h
                  Time Spent - 8h 10m
                  8h 10m