Hi Robbie, I assumed, maybe too preemptively, that object messages shouldn't be interoperable between jms and nms as JVM and CLR are not binary compatible.
Regarding to "x-opt-jms-msg-type" annotations, are you inclining that it might be a better idea to introduce our own annotations for nms, e.i. "x-opt-nms-msg-type"? Thanks, Krzysztof Porebski On Fri, Sep 6, 2019 at 12:58 PM <[email protected]> wrote: > I think youre right there. We have ability to check a .net producer and > java consumer. Will check it out quick. > > > > > Thanks for looking over > > > > > Get Outlook for Android > > > > > > > > On Fri, Sep 6, 2019 at 11:00 AM +0100, "Robbie Gemmell" < > [email protected]> wrote: > > > > > > > > > > > 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 > > On Fri, 6 Sep 2019 at 07:46, wrote: > > > > Hi All, > > > > > > > > > > There has been some real sterling work and collaboration on updating the > .NET client offering, with some of our .net community progressing the NMS > AMQP client, and is really at a great place ready for release. > > > > > > > > > > As such i will be looking to start a release early next week. > > > > > > > > > > If any last bits and bobs need adding please pr them if you want them in > this release. > > > > > > > > > > > > > > Best > > > > > > Mike > > > > > > > > > > Get Outlook for Android > > > > > > > > > > > >
