Ok Robbie, I am going to apply your suggestions. Thank you for your insight.
On Thu, Sep 12, 2019 at 11:14 AM Robbie Gemmell <[email protected]> wrote: > 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] > .invalid> > > >> 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 > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > >
