I believe so yes, notice that my comments were always specifically about the serialized object payload messages.
On Wed, 11 Sep 2019 at 21:56, Krzysztof <[email protected]> wrote: > > And what about AmqpTypedObjects that do not > have "application/x-dotnet-serialized-object" nor > "application/x-java-serialized-object" content type? Can I safely add JMS > mapping message type to them? > > On Wed, Sep 11, 2019 at 9:57 PM Robbie Gemmell <[email protected]> > wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
