Even though it is annotated as a JMS ObjectMessage, simply observe the content type as well before treating it as an NMS Object Message, i.e check if the content type is also "application/x-java-serialized-object", and if so then you know it must be treated as e.g. BytesMessage instead.
On Wed, 11 Sep 2019 at 23:02, Krzysztof <[email protected]> wrote: > > 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 > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > >
