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" <[email protected]> > To: [email protected] > 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:[email protected]] > >>>> Sent: Tuesday, December 20, 2011 12:46 PM > >>>> To: [email protected] > >>>> 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:[email protected] > >>> > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> Apache Qpid - AMQP Messaging Implementation > >> Project: http://qpid.apache.org > >> Use/Interact: mailto:[email protected] > >> > > > > --------------------------------------------------------------------- > > Apache Qpid - AMQP Messaging Implementation > > Project: http://qpid.apache.org > > Use/Interact: mailto:[email protected] > > > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
