NMS AMQP Client

[mi...@me.com.INVALID]

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

Re: NMS AMQP Client

[Robbie Gemmell <ro...@gmail.com>]

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 <h4...@gmail.com> 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 <ro...@gmail.com>
> 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 <h4...@gmail.com> 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 <mi...@me.com.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" <h4...@gmail.com>
> > > > 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" <
> > > > > > > robbie.gemmell@gmail.com> 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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >

Re: NMS AMQP Client

[Krzysztof <h4...@gmail.com>]

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 <ro...@gmail.com>
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 <h4...@gmail.com> 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 <h4...@gmail.com> 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 <
> robbie.gemmell@gmail.com>
> > > 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 <h4...@gmail.com> 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 <michael.andre.pearce@me.com
> .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" <
> h4vret@gmail.com>
> > >> > > 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" <
> > >> > > > > > robbie.gemmell@gmail.com> 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
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >>
> > >
>

Re: NMS AMQP Client

[Robbie Gemmell <ro...@gmail.com>]

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 <h4...@gmail.com> 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 <h4...@gmail.com> 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 <ro...@gmail.com>
> > 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 <h4...@gmail.com> 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 <mi...@me.com.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" <h4...@gmail.com>
> >> > > 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" <
> >> > > > > > robbie.gemmell@gmail.com> 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
> >> > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >>
> >

Re: NMS AMQP Client

[Krzysztof <h4...@gmail.com>]

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 <h4...@gmail.com> 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 <ro...@gmail.com>
> 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 <h4...@gmail.com> 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 <mi...@me.com.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" <h4...@gmail.com>
>> > > 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" <
>> > > > > > robbie.gemmell@gmail.com> 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
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>>
>

Re: NMS AMQP Client

[Krzysztof <h4...@gmail.com>]

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 <ro...@gmail.com>
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 <h4...@gmail.com> 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 <mi...@me.com.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" <h4...@gmail.com>
> > > 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" <
> > > > > > robbie.gemmell@gmail.com> 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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
>

Re: NMS AMQP Client

[Robbie Gemmell <ro...@gmail.com>]

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 <h4...@gmail.com> 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 <mi...@me.com.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" <h4...@gmail.com>
> > 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" <
> > > > > robbie.gemmell@gmail.com> 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
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> >
> >
> >
> >
> >
> >

Re: NMS AMQP Client

[Krzysztof <h4...@gmail.com>]

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 <mi...@me.com.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" <h4...@gmail.com>
> 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" <
> > > > robbie.gemmell@gmail.com> 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
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >
>
>
>
>
>
>

Re: NMS AMQP Client

[mi...@me.com.INVALID]

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" <h4...@gmail.com> 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" <
> > > robbie.gemmell@gmail.com> 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
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
>

Re: NMS AMQP Client

[Robbie Gemmell <ro...@gmail.com>]

I dont think it would be all that strange to set it when its
appropriate/valid to do so but omit it when it isnt. You could omit it
in other cases, as could the JMS client itself and maybe it will in
future. I'm only really interested here with it not being set to an
innapropriate/invalid value on these particular messages with
serialised dotnet object content. I'd probably avoid creating a new
annotation unelss/until actually required.

On Fri, 6 Sep 2019 at 15:43, Krzysztof <h4...@gmail.com> 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 <ro...@gmail.com>
> 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 <h4...@gmail.com> 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 <mi...@me.com.invalid>
> > 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" <
> > > > robbie.gemmell@gmail.com> 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
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> >

Re: NMS AMQP Client

[Krzysztof <h4...@gmail.com>]

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 <ro...@gmail.com>
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 <h4...@gmail.com> 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 <mi...@me.com.invalid>
> 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" <
> > > robbie.gemmell@gmail.com> 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
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
>

Re: NMS AMQP Client

[Robbie Gemmell <ro...@gmail.com>]

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 <h4...@gmail.com> 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 <mi...@me.com.invalid> 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" <
> > robbie.gemmell@gmail.com> 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
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >

Re: NMS AMQP Client

[Krzysztof <h4...@gmail.com>]

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 <mi...@me.com.invalid> 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" <
> robbie.gemmell@gmail.com> 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
> >
> >
> >
>
>
>
>
>
>

Re: NMS AMQP Client

[mi...@me.com.INVALID]

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" <ro...@gmail.com> 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
>
>
>

Re: NMS AMQP Client

[Robbie Gemmell <ro...@gmail.com>]

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, <mi...@me.com.invalid> 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
>
>
>