They arent really interoperable overall and thats fine, its just the specific manner in this case which would be the issue...since the NMS client seems like it would stamp its object message with an annotation saying the contents are a JMS ObjectMessage when it clearly isn't.
I'm not saying the NMS client needs its own annotation, just that it shouldnt explicitly set the one from the JMS mapping in a clearly invalid manner (as it appears it would in this case) and so should instead omit the annotation in that case. Robbie On Fri, 6 Sep 2019 at 14:47, Krzysztof <[email protected]> wrote: > > 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 > > > > > > > > > > > > > > > > > > > > >
