If the NMS client were to send a dotnet serialized object payload in a data section carrying "application/x-dotnet-serialized-object" content type, without any annotation, then it would treat that as an object message on reciept based on its content type. In that direction, the only issue was that it shouldnt set the AMQP JMS mapping message type annotation to a clearly illegal value. It is seemingly only doing so in that one case, and hence my suggestion to stop that.
Going in the other direction, its obviously fine and expected for the JMS client to set the JMS mapping annotation on a java serialized JMS ObjectMessage. In that case, I'd expect the receiving NMS client to disregard the annotation value being for a JMS ObjectMessage, since its known that it isnt actually a JMS client to begin with, and it can obviously be seen that the content type is "application/x-java-serialized-object" in that case and mean it cant be treated as an NMS ObjectMessage but rather as e.g a bytes message. I'm encouraging you not to create another annnotation because I wrote those bits of the JMS client+mapping and I'm saying you dont need one essentially. You can use the existing annotation where it is valid to do so and/or makes sense, or use none at all in many cases, especially where it is invalid such as the serialized dotnet object payload. Robbie On Wed, 11 Sep 2019 at 20:11, Krzysztof <[email protected]> wrote: > > I've checked it and I can confirm, that object type messages sent by > NMS-amqp, are recognized by qpid-jms as object messages, and they cannot be > interpreted as bytes messages with the current implementation. > Unfortunately, if we skip x-opt-jms-msg-type header for them in order to > let qpid-jms to fallback to byte message type, we will end up with exactly > the same behavior in nms. We will have to come up with the solution that > satisfies both parties. My inclination would be, as Michael and myself > suggested, to go with our own header and relay on fallback mechanism when > talking to jms. > > I'm open to your thoughts and suggestion, though. > > All the best, > Krzysztof Porebski > > On Wed, Sep 11, 2019 at 7:01 PM <[email protected]> wrote: > > > A nms specific one seems reasonable compromise here and would give some > > sort of consistency > > > > > > > > > > Get Outlook for Android > > > > > > > > > > > > > > > > On Fri, Sep 6, 2019 at 3:43 PM +0100, "Krzysztof" <[email protected]> > > wrote: > > > > > > > > > > > > > > > > > > > > > > I see what you mean but wouldn't it be a bit strange if we skipped this > > stamp for this particular type of message and left it for other types. If > > we change the annotation to nms specific we could keep messages consistent, > > and as you pointed out, jms would be still able to infer types from the > > content of the payload. > > > > I'm not implying that this is the best solution, just thinking out loud. > > > > On Fri, Sep 6, 2019 at 4:27 PM Robbie Gemmell > > wrote: > > > > > 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 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 > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
