You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Jan Bares <ja...@wood.cz> on 2011/12/20 11:04:01 UTC
.NET to Java JMS interoperability
Hi,
is it possible to pass messages from .NET to Java JMS that will appear as TextMessage in JMS? Currently messages appears in JMS as BytesMessage. We have not found any way how to control this from .NET API.
Thank you, Jan
DISCLAIMER
WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Romania by the CNVM, in Slovakia by the NBS and in the UK by the FSA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.cz under section Corporate Governance.
Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
RE: .NET to Java JMS interoperability
Posted by Jan Bares <ja...@wood.cz>.
Back to my original question. I looked into Java client sources, and it seems that content-type "text/plain" or "text/xml" will create TextMessage on JMS side. We will test it.
Jan
> > >>
> > >> Jan Bares wrote:
> > >>> Thanks for your time and answer. I was just affraid that we
> > >>> missed
> > >>> something as the .NET API is not very well documented. I am
> > >>> already
> > >>> aware of the encoding and content-type methods on C++/.NET API
> > >>> and I
> > >>> was thinking that for instance specific content-type may trigger
> > >>> JMS
> > >>> to interpret data as TextMessage. Certainly looking into sources
> > >>> will
> > >>> help a lot.
> > >>>
> > >>> Thanks, Jan
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
> > >>>> Sent: Tuesday, December 20, 2011 12:46 PM
> > >>>> To: users@qpid.apache.org
> > >>>> Subject: Re: .NET to Java JMS interoperability
> > >>>>
> > >>>> Hmmm,
> > >>>> That's an interesting in a more general sense with respect to
> > >>>> interoperability.
> > >>>>
> > >>>> My suspicion is that there are only a few types that will safely
> > >>>> interoperate. Octet arrays are clearly one and I believe that
> > >>>> Map
> > >>>> messages are another way to (fairly) safely interoperate. I say
> > >>>> fairly
> > >>>> because there are still issues, for example in C++ creating
> > >>>> Variant
> > >>>> stings defaults to a binary representation that is represented
> > >>>> in Java
> > >>>> as a byte[] so you need to do setEncoding("utf8") to have them
> > >>>> encoded
> > >>>> as strings that Java can safely interpret (I usually end up
> > >>>> writing a
> > >>>> fair bit of defensive code to interpret types).
> > >>>>
> > >>>> One approach might be to use the content-type header to inform
> > >>>> your
> > >>>> application how to interpret the bytes, but that's not trivial
> > >>>> either
> > >>>> as
> > >>>> the content-type isn't visible in pure JMS I had to cast to the
> > >>>> underlying implementation e.g.
> > >>>>
> > >>>>
> > >>>>
> ((org.apache.qpid.client.message.AbstractJMSMessage)message).setContent
> > >>>> Type("amqp/list");
> > >>>>
> > >>>> Which isn't ideal and isn't technically a supportable approach.
> > >>>>
> > >>>> Sorry I can't give a more direct answer to your specific
> > >>>> question, but
> > >>>> I
> > >>>> hope it's of some help.
> > >>>>
> > >>>> Frase
> > >>>>
> > >>>> Jan Bares wrote:
> > >>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> is it possible to pass messages from .NET to Java JMS that will
> > >>>>>
> > >>>> appear as TextMessage in JMS? Currently messages appears in JMS
> > >>>> as
> > >>>> BytesMessage. We have not found any way how to control this from
> > >>>> .NET
> > >>>> API.
> > >>>>
> > >>>>> Thank you, Jan
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> DISCLAIMER
> > >>> WOOD & Company Financial Services, a.s. and its branches are
> > >>> authorized and regulated by the CNB as Home State regulator and
> > >>> in
> > >>> Poland by the KNF, in Romania by the CNVM, in Slovakia by the NBS
> > >>> and
> > >>> in the UK by the FSA as Host State regulators. For further
> > >>> information about WOOD & Co., its investment services, financial
> > >>> instruments and associated risks, safeguard client assets (incl.
> > >>> compensation schemes) and contractual relationship please see our
> > >>> website at www.wood.cz under section Corporate Governance.
> > >>> Unless otherwise stated, this transmission is neither an offer
> > >>> nor
> > >>> the solicitation of an offer to sell or purchase any investment.
> > >>> All
> > >>> estimates, opinions and other information contained herein are
> > >>> subject to change without notice and are provided in good faith
> > >>> but
> > >>> without legal responsibility or liability. Opinion may be
> > >>> personal to
> > >>> the author and may not reflect the opinions of WOOD & Co.
> > >>> Communications from sales persons, sales traders or traders
> > >>> should
> > >>> not be regarded as investment research and may contain opinions
> > >>> or
> > >>> trading ideas which are different from WOOD & Co. investment
> > >>> research opinions.
> > >>> This e-mail and any attachments are confidential and may be
> > >>> privileged or otherwise protected from disclosure. If you are not
> > >>> a
> > >>> named addressee you must not use, disclose, distribute, copy,
> > >>> print
> > >>> or rely on this e-mail and any of its attachments. Please notify
> > >>> the
> > >>> sender that you have received this email by mistake by replying
> > >>> to
> > >>> the email, and then delete the email and any copies of it.
> > >>> Although
> > >>> WOOD & Co. routinely screens e-mails for viruses, addressees
> > >>> should
> > >>> scan this e-mail and any attachments for viruses. WOOD & Co.
> > >>> makes no
> > >>> representation or warranty as to the absence of viruses in this
> > >>> e-mail or any attachments. Please note that to ensure regulatory
> > >>> compliance and for the protection of our clients and business, we
> > >>> may
> > >>> monitor and read e-mails sent to and from our server(s).
> > >>>
> > >>>
> > >>>
> > >>> -----------------------------------------------------------------
> ----
> > >>> Apache Qpid - AMQP Messaging Implementation
> > >>> Project: http://qpid.apache.org
> > >>> Use/Interact: mailto:users-subscribe@qpid.apache.org
> > >>>
> > >>>
> > >>>
> > >>
> > >> ------------------------------------------------------------------
> ---
> > >> Apache Qpid - AMQP Messaging Implementation
> > >> Project: http://qpid.apache.org
> > >> Use/Interact: mailto:users-subscribe@qpid.apache.org
> > >>
> > >
> > > -------------------------------------------------------------------
> --
> > > Apache Qpid - AMQP Messaging Implementation
> > > Project: http://qpid.apache.org
> > > Use/Interact: mailto:users-subscribe@qpid.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:users-subscribe@qpid.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
DISCLAIMER
WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Romania by the CNVM, in Slovakia by the NBS and in the UK by the FSA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.cz under section Corporate Governance.
Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
Re: .NET to Java JMS interoperability
Posted by Chuck Rolke <cr...@redhat.com>.
The .NET Binding to C++ Messaging is not a swig binding. It is a full, C++/CLR interop package that directly connects managed .NET languages with the C++ Messaging client. If a native C++ client can send a specific message then so can your .NET client.
-Chuck
----- Original Message -----
> From: "Carl Trieloff" <cc...@redhat.com>
> To: users@qpid.apache.org
> Sent: Tuesday, December 20, 2011 1:02:32 PM
> Subject: Re: .NET to Java JMS interoperability
>
>
>
> Here is the JMS example
>
> http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch03s04.html
>
>
>
> On 12/20/2011 12:55 PM, Carl Trieloff wrote:
> >
> > Take a look at this section of the doc
> >
> > http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch02s11.html
> >
> > examples for C++, .NET and JMS.
> >
> > Carl.
> >
> >
> > On 12/20/2011 12:46 PM, Fraser Adams wrote:
> >> Hi Jan,
> >> ISTR reading at one point that the .NET binding is a SWIG wrapper
> >> around the C++ qpid::messaging (though I could have just imagined
> >> reading that :-)).
> >>
> >> One thought if that is the case (totally an idle musing and I've
> >> no
> >> idea if it would work - I've definitely not tried it!!) is whether
> >> it
> >> would be possible to send a Variant string with an encoding set to
> >> utf8 as the message content. "just maybe" that'll get interpreted
> >> as a
> >> TextMessage. As I said previously variant strings with default
> >> encoding are treated as byte[] when sent as Map contents but if
> >> the
> >> encoding is set to utf8 they are treated as String when sent as
> >> Map
> >> contents.
> >>
> >> It's worth a punt, but I rather suspect that your most likely
> >> options
> >> are:
> >> a) Sent your data as an octet array and make an assumption based
> >> on a
> >> "bilateral agreement" that the octet array is a utf8 string and
> >> use
> >> that to construct a Java String.
> >> b) Sent the data as above but pass a content-type to explicitly
> >> tell
> >> the consumer that this is indeed a utf8 string (though as I
> >> mentioned
> >> before getting the content-type in Java is a bit of a faff).
> >> c) Write your text as a Variant string with utf8 encoding to be
> >> stored
> >> in a Map and sent the Map message. As I mentioned previously most
> >> of
> >> the documentation in programming in Apache Qpid at least alludes
> >> to
> >> the fact that Map messages are likely to be the way to go if you
> >> need
> >> to interoperate.
> >>
> >> As it happens QMF2 uses Map Messages extensively to interoperate
> >> (definitely works between Java/C++/Python) but as I mentioned
> >> previously it's not foolproof and I had to incorporate quite a bit
> >> of
> >> defensive programming to avoid a world of ClassCastException fun
> >> as
> >> what gets returned is far from consistent :-)
> >>
> >> There are inconsistencies even with quite important things, for
> >> example there was a bug with the qpid::messaging AddressParser
> >> that
> >> resulted in headers exchange bindings in Address Strings getting
> >> mapped as binary strings, which would never map headers created in
> >> say
> >> a Java application - Gordon Sim has fixed that recently, but I
> >> expect
> >> there are a few other edge cases floating around to trap the
> >> unwary.
> >>
> >> Still life would be boring if it was all easy :-D
> >>
> >> Frase
> >>
> >>
> >> Jan Bares wrote:
> >>> Thanks for your time and answer. I was just affraid that we
> >>> missed
> >>> something as the .NET API is not very well documented. I am
> >>> already
> >>> aware of the encoding and content-type methods on C++/.NET API
> >>> and I
> >>> was thinking that for instance specific content-type may trigger
> >>> JMS
> >>> to interpret data as TextMessage. Certainly looking into sources
> >>> will
> >>> help a lot.
> >>>
> >>> Thanks, Jan
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
> >>>> Sent: Tuesday, December 20, 2011 12:46 PM
> >>>> To: users@qpid.apache.org
> >>>> Subject: Re: .NET to Java JMS interoperability
> >>>>
> >>>> Hmmm,
> >>>> That's an interesting in a more general sense with respect to
> >>>> interoperability.
> >>>>
> >>>> My suspicion is that there are only a few types that will safely
> >>>> interoperate. Octet arrays are clearly one and I believe that
> >>>> Map
> >>>> messages are another way to (fairly) safely interoperate. I say
> >>>> fairly
> >>>> because there are still issues, for example in C++ creating
> >>>> Variant
> >>>> stings defaults to a binary representation that is represented
> >>>> in Java
> >>>> as a byte[] so you need to do setEncoding("utf8") to have them
> >>>> encoded
> >>>> as strings that Java can safely interpret (I usually end up
> >>>> writing a
> >>>> fair bit of defensive code to interpret types).
> >>>>
> >>>> One approach might be to use the content-type header to inform
> >>>> your
> >>>> application how to interpret the bytes, but that's not trivial
> >>>> either
> >>>> as
> >>>> the content-type isn't visible in pure JMS I had to cast to the
> >>>> underlying implementation e.g.
> >>>>
> >>>>
> >>>> ((org.apache.qpid.client.message.AbstractJMSMessage)message).setContent
> >>>> Type("amqp/list");
> >>>>
> >>>> Which isn't ideal and isn't technically a supportable approach.
> >>>>
> >>>> Sorry I can't give a more direct answer to your specific
> >>>> question, but
> >>>> I
> >>>> hope it's of some help.
> >>>>
> >>>> Frase
> >>>>
> >>>> Jan Bares wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> is it possible to pass messages from .NET to Java JMS that will
> >>>>>
> >>>> appear as TextMessage in JMS? Currently messages appears in JMS
> >>>> as
> >>>> BytesMessage. We have not found any way how to control this from
> >>>> .NET
> >>>> API.
> >>>>
> >>>>> Thank you, Jan
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>>
> >>> DISCLAIMER
> >>> WOOD & Company Financial Services, a.s. and its branches are
> >>> authorized and regulated by the CNB as Home State regulator and
> >>> in
> >>> Poland by the KNF, in Romania by the CNVM, in Slovakia by the NBS
> >>> and
> >>> in the UK by the FSA as Host State regulators. For further
> >>> information about WOOD & Co., its investment services, financial
> >>> instruments and associated risks, safeguard client assets (incl.
> >>> compensation schemes) and contractual relationship please see our
> >>> website at www.wood.cz under section Corporate Governance.
> >>> Unless otherwise stated, this transmission is neither an offer
> >>> nor
> >>> the solicitation of an offer to sell or purchase any investment.
> >>> All
> >>> estimates, opinions and other information contained herein are
> >>> subject to change without notice and are provided in good faith
> >>> but
> >>> without legal responsibility or liability. Opinion may be
> >>> personal to
> >>> the author and may not reflect the opinions of WOOD & Co.
> >>> Communications from sales persons, sales traders or traders
> >>> should
> >>> not be regarded as investment research and may contain opinions
> >>> or
> >>> trading ideas which are different from WOOD & Co. investment
> >>> research opinions.
> >>> This e-mail and any attachments are confidential and may be
> >>> privileged or otherwise protected from disclosure. If you are not
> >>> a
> >>> named addressee you must not use, disclose, distribute, copy,
> >>> print
> >>> or rely on this e-mail and any of its attachments. Please notify
> >>> the
> >>> sender that you have received this email by mistake by replying
> >>> to
> >>> the email, and then delete the email and any copies of it.
> >>> Although
> >>> WOOD & Co. routinely screens e-mails for viruses, addressees
> >>> should
> >>> scan this e-mail and any attachments for viruses. WOOD & Co.
> >>> makes no
> >>> representation or warranty as to the absence of viruses in this
> >>> e-mail or any attachments. Please note that to ensure regulatory
> >>> compliance and for the protection of our clients and business, we
> >>> may
> >>> monitor and read e-mails sent to and from our server(s).
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> Apache Qpid - AMQP Messaging Implementation
> >>> Project: http://qpid.apache.org
> >>> Use/Interact: mailto:users-subscribe@qpid.apache.org
> >>>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> Apache Qpid - AMQP Messaging Implementation
> >> Project: http://qpid.apache.org
> >> Use/Interact: mailto:users-subscribe@qpid.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:users-subscribe@qpid.apache.org
> >
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: .NET to Java JMS interoperability
Posted by Carl Trieloff <cc...@redhat.com>.
Here is the JMS example
http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch03s04.html
On 12/20/2011 12:55 PM, Carl Trieloff wrote:
>
> Take a look at this section of the doc
>
> http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch02s11.html
>
> examples for C++, .NET and JMS.
>
> Carl.
>
>
> On 12/20/2011 12:46 PM, Fraser Adams wrote:
>> Hi Jan,
>> ISTR reading at one point that the .NET binding is a SWIG wrapper
>> around the C++ qpid::messaging (though I could have just imagined
>> reading that :-)).
>>
>> One thought if that is the case (totally an idle musing and I've no
>> idea if it would work - I've definitely not tried it!!) is whether it
>> would be possible to send a Variant string with an encoding set to
>> utf8 as the message content. "just maybe" that'll get interpreted as a
>> TextMessage. As I said previously variant strings with default
>> encoding are treated as byte[] when sent as Map contents but if the
>> encoding is set to utf8 they are treated as String when sent as Map
>> contents.
>>
>> It's worth a punt, but I rather suspect that your most likely options
>> are:
>> a) Sent your data as an octet array and make an assumption based on a
>> "bilateral agreement" that the octet array is a utf8 string and use
>> that to construct a Java String.
>> b) Sent the data as above but pass a content-type to explicitly tell
>> the consumer that this is indeed a utf8 string (though as I mentioned
>> before getting the content-type in Java is a bit of a faff).
>> c) Write your text as a Variant string with utf8 encoding to be stored
>> in a Map and sent the Map message. As I mentioned previously most of
>> the documentation in programming in Apache Qpid at least alludes to
>> the fact that Map messages are likely to be the way to go if you need
>> to interoperate.
>>
>> As it happens QMF2 uses Map Messages extensively to interoperate
>> (definitely works between Java/C++/Python) but as I mentioned
>> previously it's not foolproof and I had to incorporate quite a bit of
>> defensive programming to avoid a world of ClassCastException fun as
>> what gets returned is far from consistent :-)
>>
>> There are inconsistencies even with quite important things, for
>> example there was a bug with the qpid::messaging AddressParser that
>> resulted in headers exchange bindings in Address Strings getting
>> mapped as binary strings, which would never map headers created in say
>> a Java application - Gordon Sim has fixed that recently, but I expect
>> there are a few other edge cases floating around to trap the unwary.
>>
>> Still life would be boring if it was all easy :-D
>>
>> Frase
>>
>>
>> Jan Bares wrote:
>>> Thanks for your time and answer. I was just affraid that we missed
>>> something as the .NET API is not very well documented. I am already
>>> aware of the encoding and content-type methods on C++/.NET API and I
>>> was thinking that for instance specific content-type may trigger JMS
>>> to interpret data as TextMessage. Certainly looking into sources will
>>> help a lot.
>>>
>>> Thanks, Jan
>>>
>>>
>>>> -----Original Message-----
>>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
>>>> Sent: Tuesday, December 20, 2011 12:46 PM
>>>> To: users@qpid.apache.org
>>>> Subject: Re: .NET to Java JMS interoperability
>>>>
>>>> Hmmm,
>>>> That's an interesting in a more general sense with respect to
>>>> interoperability.
>>>>
>>>> My suspicion is that there are only a few types that will safely
>>>> interoperate. Octet arrays are clearly one and I believe that Map
>>>> messages are another way to (fairly) safely interoperate. I say fairly
>>>> because there are still issues, for example in C++ creating Variant
>>>> stings defaults to a binary representation that is represented in Java
>>>> as a byte[] so you need to do setEncoding("utf8") to have them
>>>> encoded
>>>> as strings that Java can safely interpret (I usually end up writing a
>>>> fair bit of defensive code to interpret types).
>>>>
>>>> One approach might be to use the content-type header to inform your
>>>> application how to interpret the bytes, but that's not trivial either
>>>> as
>>>> the content-type isn't visible in pure JMS I had to cast to the
>>>> underlying implementation e.g.
>>>>
>>>>
>>>> ((org.apache.qpid.client.message.AbstractJMSMessage)message).setContent
>>>> Type("amqp/list");
>>>>
>>>> Which isn't ideal and isn't technically a supportable approach.
>>>>
>>>> Sorry I can't give a more direct answer to your specific question, but
>>>> I
>>>> hope it's of some help.
>>>>
>>>> Frase
>>>>
>>>> Jan Bares wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> is it possible to pass messages from .NET to Java JMS that will
>>>>>
>>>> appear as TextMessage in JMS? Currently messages appears in JMS as
>>>> BytesMessage. We have not found any way how to control this from .NET
>>>> API.
>>>>
>>>>> Thank you, Jan
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
>>> DISCLAIMER
>>> WOOD & Company Financial Services, a.s. and its branches are
>>> authorized and regulated by the CNB as Home State regulator and in
>>> Poland by the KNF, in Romania by the CNVM, in Slovakia by the NBS and
>>> in the UK by the FSA as Host State regulators. For further
>>> information about WOOD & Co., its investment services, financial
>>> instruments and associated risks, safeguard client assets (incl.
>>> compensation schemes) and contractual relationship please see our
>>> website at www.wood.cz under section Corporate Governance.
>>> Unless otherwise stated, this transmission is neither an offer nor
>>> the solicitation of an offer to sell or purchase any investment. All
>>> estimates, opinions and other information contained herein are
>>> subject to change without notice and are provided in good faith but
>>> without legal responsibility or liability. Opinion may be personal to
>>> the author and may not reflect the opinions of WOOD & Co.
>>> Communications from sales persons, sales traders or traders should
>>> not be regarded as investment research and may contain opinions or
>>> trading ideas which are different from WOOD & Co. investment
>>> research opinions.
>>> This e-mail and any attachments are confidential and may be
>>> privileged or otherwise protected from disclosure. If you are not a
>>> named addressee you must not use, disclose, distribute, copy, print
>>> or rely on this e-mail and any of its attachments. Please notify the
>>> sender that you have received this email by mistake by replying to
>>> the email, and then delete the email and any copies of it. Although
>>> WOOD & Co. routinely screens e-mails for viruses, addressees should
>>> scan this e-mail and any attachments for viruses. WOOD & Co. makes no
>>> representation or warranty as to the absence of viruses in this
>>> e-mail or any attachments. Please note that to ensure regulatory
>>> compliance and for the protection of our clients and business, we may
>>> monitor and read e-mails sent to and from our server(s).
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project: http://qpid.apache.org
>>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: .NET to Java JMS interoperability
Posted by Carl Trieloff <cc...@redhat.com>.
Take a look at this section of the doc
http://qpid.apache.org/books/0.12/Programming-In-Apache-Qpid/html/ch02s11.html
examples for C++, .NET and JMS.
Carl.
On 12/20/2011 12:46 PM, Fraser Adams wrote:
> Hi Jan,
> ISTR reading at one point that the .NET binding is a SWIG wrapper
> around the C++ qpid::messaging (though I could have just imagined
> reading that :-)).
>
> One thought if that is the case (totally an idle musing and I've no
> idea if it would work - I've definitely not tried it!!) is whether it
> would be possible to send a Variant string with an encoding set to
> utf8 as the message content. "just maybe" that'll get interpreted as a
> TextMessage. As I said previously variant strings with default
> encoding are treated as byte[] when sent as Map contents but if the
> encoding is set to utf8 they are treated as String when sent as Map
> contents.
>
> It's worth a punt, but I rather suspect that your most likely options
> are:
> a) Sent your data as an octet array and make an assumption based on a
> "bilateral agreement" that the octet array is a utf8 string and use
> that to construct a Java String.
> b) Sent the data as above but pass a content-type to explicitly tell
> the consumer that this is indeed a utf8 string (though as I mentioned
> before getting the content-type in Java is a bit of a faff).
> c) Write your text as a Variant string with utf8 encoding to be stored
> in a Map and sent the Map message. As I mentioned previously most of
> the documentation in programming in Apache Qpid at least alludes to
> the fact that Map messages are likely to be the way to go if you need
> to interoperate.
>
> As it happens QMF2 uses Map Messages extensively to interoperate
> (definitely works between Java/C++/Python) but as I mentioned
> previously it's not foolproof and I had to incorporate quite a bit of
> defensive programming to avoid a world of ClassCastException fun as
> what gets returned is far from consistent :-)
>
> There are inconsistencies even with quite important things, for
> example there was a bug with the qpid::messaging AddressParser that
> resulted in headers exchange bindings in Address Strings getting
> mapped as binary strings, which would never map headers created in say
> a Java application - Gordon Sim has fixed that recently, but I expect
> there are a few other edge cases floating around to trap the unwary.
>
> Still life would be boring if it was all easy :-D
>
> Frase
>
>
> Jan Bares wrote:
>> Thanks for your time and answer. I was just affraid that we missed
>> something as the .NET API is not very well documented. I am already
>> aware of the encoding and content-type methods on C++/.NET API and I
>> was thinking that for instance specific content-type may trigger JMS
>> to interpret data as TextMessage. Certainly looking into sources will
>> help a lot.
>>
>> Thanks, Jan
>>
>>
>>> -----Original Message-----
>>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
>>> Sent: Tuesday, December 20, 2011 12:46 PM
>>> To: users@qpid.apache.org
>>> Subject: Re: .NET to Java JMS interoperability
>>>
>>> Hmmm,
>>> That's an interesting in a more general sense with respect to
>>> interoperability.
>>>
>>> My suspicion is that there are only a few types that will safely
>>> interoperate. Octet arrays are clearly one and I believe that Map
>>> messages are another way to (fairly) safely interoperate. I say fairly
>>> because there are still issues, for example in C++ creating Variant
>>> stings defaults to a binary representation that is represented in Java
>>> as a byte[] so you need to do setEncoding("utf8") to have them
>>> encoded
>>> as strings that Java can safely interpret (I usually end up writing a
>>> fair bit of defensive code to interpret types).
>>>
>>> One approach might be to use the content-type header to inform your
>>> application how to interpret the bytes, but that's not trivial either
>>> as
>>> the content-type isn't visible in pure JMS I had to cast to the
>>> underlying implementation e.g.
>>>
>>>
>>> ((org.apache.qpid.client.message.AbstractJMSMessage)message).setContent
>>> Type("amqp/list");
>>>
>>> Which isn't ideal and isn't technically a supportable approach.
>>>
>>> Sorry I can't give a more direct answer to your specific question, but
>>> I
>>> hope it's of some help.
>>>
>>> Frase
>>>
>>> Jan Bares wrote:
>>>
>>>> Hi,
>>>>
>>>> is it possible to pass messages from .NET to Java JMS that will
>>>>
>>> appear as TextMessage in JMS? Currently messages appears in JMS as
>>> BytesMessage. We have not found any way how to control this from .NET
>>> API.
>>>
>>>> Thank you, Jan
>>>>
>>>>
>>>>
>>
>>
>>
>>
>>
>> DISCLAIMER
>> WOOD & Company Financial Services, a.s. and its branches are
>> authorized and regulated by the CNB as Home State regulator and in
>> Poland by the KNF, in Romania by the CNVM, in Slovakia by the NBS and
>> in the UK by the FSA as Host State regulators. For further
>> information about WOOD & Co., its investment services, financial
>> instruments and associated risks, safeguard client assets (incl.
>> compensation schemes) and contractual relationship please see our
>> website at www.wood.cz under section Corporate Governance.
>> Unless otherwise stated, this transmission is neither an offer nor
>> the solicitation of an offer to sell or purchase any investment. All
>> estimates, opinions and other information contained herein are
>> subject to change without notice and are provided in good faith but
>> without legal responsibility or liability. Opinion may be personal to
>> the author and may not reflect the opinions of WOOD & Co.
>> Communications from sales persons, sales traders or traders should
>> not be regarded as investment research and may contain opinions or
>> trading ideas which are different from WOOD & Co. investment
>> research opinions.
>> This e-mail and any attachments are confidential and may be
>> privileged or otherwise protected from disclosure. If you are not a
>> named addressee you must not use, disclose, distribute, copy, print
>> or rely on this e-mail and any of its attachments. Please notify the
>> sender that you have received this email by mistake by replying to
>> the email, and then delete the email and any copies of it. Although
>> WOOD & Co. routinely screens e-mails for viruses, addressees should
>> scan this e-mail and any attachments for viruses. WOOD & Co. makes no
>> representation or warranty as to the absence of viruses in this
>> e-mail or any attachments. Please note that to ensure regulatory
>> compliance and for the protection of our clients and business, we may
>> monitor and read e-mails sent to and from our server(s).
>>
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: .NET to Java JMS interoperability
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hi Jan,
ISTR reading at one point that the .NET binding is a SWIG wrapper around
the C++ qpid::messaging (though I could have just imagined reading that
:-)).
One thought if that is the case (totally an idle musing and I've no idea
if it would work - I've definitely not tried it!!) is whether it would
be possible to send a Variant string with an encoding set to utf8 as the
message content. "just maybe" that'll get interpreted as a TextMessage.
As I said previously variant strings with default encoding are treated
as byte[] when sent as Map contents but if the encoding is set to utf8
they are treated as String when sent as Map contents.
It's worth a punt, but I rather suspect that your most likely options are:
a) Sent your data as an octet array and make an assumption based on a
"bilateral agreement" that the octet array is a utf8 string and use that
to construct a Java String.
b) Sent the data as above but pass a content-type to explicitly tell the
consumer that this is indeed a utf8 string (though as I mentioned before
getting the content-type in Java is a bit of a faff).
c) Write your text as a Variant string with utf8 encoding to be stored
in a Map and sent the Map message. As I mentioned previously most of the
documentation in programming in Apache Qpid at least alludes to the fact
that Map messages are likely to be the way to go if you need to
interoperate.
As it happens QMF2 uses Map Messages extensively to interoperate
(definitely works between Java/C++/Python) but as I mentioned previously
it's not foolproof and I had to incorporate quite a bit of defensive
programming to avoid a world of ClassCastException fun as what gets
returned is far from consistent :-)
There are inconsistencies even with quite important things, for example
there was a bug with the qpid::messaging AddressParser that resulted in
headers exchange bindings in Address Strings getting mapped as binary
strings, which would never map headers created in say a Java application
- Gordon Sim has fixed that recently, but I expect there are a few other
edge cases floating around to trap the unwary.
Still life would be boring if it was all easy :-D
Frase
Jan Bares wrote:
> Thanks for your time and answer. I was just affraid that we missed something as the .NET API is not very well documented. I am already aware of the encoding and content-type methods on C++/.NET API and I was thinking that for instance specific content-type may trigger JMS to interpret data as TextMessage. Certainly looking into sources will help a lot.
>
> Thanks, Jan
>
>
>> -----Original Message-----
>> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
>> Sent: Tuesday, December 20, 2011 12:46 PM
>> To: users@qpid.apache.org
>> Subject: Re: .NET to Java JMS interoperability
>>
>> Hmmm,
>> That's an interesting in a more general sense with respect to
>> interoperability.
>>
>> My suspicion is that there are only a few types that will safely
>> interoperate. Octet arrays are clearly one and I believe that Map
>> messages are another way to (fairly) safely interoperate. I say fairly
>> because there are still issues, for example in C++ creating Variant
>> stings defaults to a binary representation that is represented in Java
>> as a byte[] so you need to do setEncoding("utf8") to have them
>> encoded
>> as strings that Java can safely interpret (I usually end up writing a
>> fair bit of defensive code to interpret types).
>>
>> One approach might be to use the content-type header to inform your
>> application how to interpret the bytes, but that's not trivial either
>> as
>> the content-type isn't visible in pure JMS I had to cast to the
>> underlying implementation e.g.
>>
>>
>> ((org.apache.qpid.client.message.AbstractJMSMessage)message).setContent
>> Type("amqp/list");
>>
>> Which isn't ideal and isn't technically a supportable approach.
>>
>> Sorry I can't give a more direct answer to your specific question, but
>> I
>> hope it's of some help.
>>
>> Frase
>>
>> Jan Bares wrote:
>>
>>> Hi,
>>>
>>> is it possible to pass messages from .NET to Java JMS that will
>>>
>> appear as TextMessage in JMS? Currently messages appears in JMS as
>> BytesMessage. We have not found any way how to control this from .NET
>> API.
>>
>>> Thank you, Jan
>>>
>>>
>>>
>
>
>
>
>
> DISCLAIMER
> WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Romania by the CNVM, in Slovakia by the NBS and in the UK by the FSA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.cz under section Corporate Governance.
>
> Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
>
> This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
RE: .NET to Java JMS interoperability
Posted by Jan Bares <ja...@wood.cz>.
Thanks for your time and answer. I was just affraid that we missed something as the .NET API is not very well documented. I am already aware of the encoding and content-type methods on C++/.NET API and I was thinking that for instance specific content-type may trigger JMS to interpret data as TextMessage. Certainly looking into sources will help a lot.
Thanks, Jan
> -----Original Message-----
> From: Fraser Adams [mailto:fraser.adams@blueyonder.co.uk]
> Sent: Tuesday, December 20, 2011 12:46 PM
> To: users@qpid.apache.org
> Subject: Re: .NET to Java JMS interoperability
>
> Hmmm,
> That's an interesting in a more general sense with respect to
> interoperability.
>
> My suspicion is that there are only a few types that will safely
> interoperate. Octet arrays are clearly one and I believe that Map
> messages are another way to (fairly) safely interoperate. I say fairly
> because there are still issues, for example in C++ creating Variant
> stings defaults to a binary representation that is represented in Java
> as a byte[] so you need to do setEncoding("utf8") to have them
> encoded
> as strings that Java can safely interpret (I usually end up writing a
> fair bit of defensive code to interpret types).
>
> One approach might be to use the content-type header to inform your
> application how to interpret the bytes, but that's not trivial either
> as
> the content-type isn't visible in pure JMS I had to cast to the
> underlying implementation e.g.
>
>
> ((org.apache.qpid.client.message.AbstractJMSMessage)message).setContent
> Type("amqp/list");
>
> Which isn't ideal and isn't technically a supportable approach.
>
> Sorry I can't give a more direct answer to your specific question, but
> I
> hope it's of some help.
>
> Frase
>
> Jan Bares wrote:
> > Hi,
> >
> > is it possible to pass messages from .NET to Java JMS that will
> appear as TextMessage in JMS? Currently messages appears in JMS as
> BytesMessage. We have not found any way how to control this from .NET
> API.
> >
> > Thank you, Jan
> >
> >
DISCLAIMER
WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Romania by the CNVM, in Slovakia by the NBS and in the UK by the FSA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.cz under section Corporate Governance.
Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: .NET to Java JMS interoperability
Posted by Fraser Adams <fr...@blueyonder.co.uk>.
Hmmm,
That's an interesting in a more general sense with respect to
interoperability.
My suspicion is that there are only a few types that will safely
interoperate. Octet arrays are clearly one and I believe that Map
messages are another way to (fairly) safely interoperate. I say fairly
because there are still issues, for example in C++ creating Variant
stings defaults to a binary representation that is represented in Java
as a byte[] so you need to do setEncoding("utf8") to have them encoded
as strings that Java can safely interpret (I usually end up writing a
fair bit of defensive code to interpret types).
One approach might be to use the content-type header to inform your
application how to interpret the bytes, but that's not trivial either as
the content-type isn't visible in pure JMS I had to cast to the
underlying implementation e.g.
((org.apache.qpid.client.message.AbstractJMSMessage)message).setContentType("amqp/list");
Which isn't ideal and isn't technically a supportable approach.
Sorry I can't give a more direct answer to your specific question, but I
hope it's of some help.
Frase
Jan Bares wrote:
> Hi,
>
> is it possible to pass messages from .NET to Java JMS that will appear as TextMessage in JMS? Currently messages appears in JMS as BytesMessage. We have not found any way how to control this from .NET API.
>
> Thank you, Jan
>
>
>
>
> DISCLAIMER
> WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Romania by the CNVM, in Slovakia by the NBS and in the UK by the FSA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.cz under section Corporate Governance.
>
> Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
>
> This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: .NET to Java JMS interoperability
Posted by Carl Trieloff <cc...@redhat.com>.
Or, use the mapped message support in Java(JMS) and.NET. The docs on
that are quite good and it uses the AMQP type system which means you get
full interop across languages, platforms etc.
I know quite a few people use it expressly for JMS <-> .NET message interop.
Carl.
On 12/20/2011 05:04 AM, Jan Bares wrote:
> Hi,
>
> is it possible to pass messages from .NET to Java JMS that will appear as TextMessage in JMS? Currently messages appears in JMS as BytesMessage. We have not found any way how to control this from .NET API.
>
> Thank you, Jan
>
>
>
>
> DISCLAIMER
> WOOD & Company Financial Services, a.s. and its branches are authorized and regulated by the CNB as Home State regulator and in Poland by the KNF, in Romania by the CNVM, in Slovakia by the NBS and in the UK by the FSA as Host State regulators. For further information about WOOD & Co., its investment services, financial instruments and associated risks, safeguard client assets (incl. compensation schemes) and contractual relationship please see our website at www.wood.cz under section Corporate Governance.
>
> Unless otherwise stated, this transmission is neither an offer nor the solicitation of an offer to sell or purchase any investment. All estimates, opinions and other information contained herein are subject to change without notice and are provided in good faith but without legal responsibility or liability. Opinion may be personal to the author and may not reflect the opinions of WOOD & Co. Communications from sales persons, sales traders or traders should not be regarded as investment research and may contain opinions or trading ideas which are different from WOOD & Co. investment research opinions.
>
> This e-mail and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not a named addressee you must not use, disclose, distribute, copy, print or rely on this e-mail and any of its attachments. Please notify the sender that you have received this email by mistake by replying to the email, and then delete the email and any copies of it. Although WOOD & Co. routinely screens e-mails for viruses, addressees should scan this e-mail and any attachments for viruses. WOOD & Co. makes no representation or warranty as to the absence of viruses in this e-mail or any attachments. Please note that to ensure regulatory compliance and for the protection of our clients and business, we may monitor and read e-mails sent to and from our server(s).
>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org