https://github.com/apache/activemq-nms-amqp/pull/31/
I tested it with qpid-jms and it seems to work fine, when .net is a producer and java is a consumer. There is a problem however when the roles change. We try still try to interpret object "x-opt-jms-msg-type" for the sake of AmqpTypedObjects but when we receive java serialized payload it breaks. Should we resign from x-opt-jms-msg-type object whatsoever? On Wed, Sep 11, 2019 at 10:56 PM 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 >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > >> > > >> > > >> > > >> > > >> > > >> > > >> >
