Created attachment 886482 [details] Modified C# helloworld example to reproduce this issue Description of problem: The SetContentObject(object) method is able to fill in the message content with given string argument, however if the argument is Dictionary<> or Collection<> type, the method raises an exception: "C:\qpid_VS2010\bin\Release>csharp.example.helloworld.exe 10.34.37.200 Exception System.NotImplementedException: The method or operation is not impleme nted. at Org.Apache.Qpid.Messaging.TypeTranslator.ManagedToNativeObject(Object mana gedValue, Variant* qpidVariant) in q:\qpid\cpp\bindings\qpid\dotnet\src\typetran slator.cpp:line 247 at Org.Apache.Qpid.Messaging.Message.SetContentObject(Object managedObject) i n q:\qpid\cpp\bindings\qpid\dotnet\src\message.cpp:line 418 at Org.Apache.Qpid.Messaging.Program.Main(String[] args) in c:\qpid_VS2010\do tnet_examples\examples\csharp.example.helloworld\csharp.example.helloworld.cs:li ne 49." Version-Release number of selected component (if applicable): qpid-cpp-win-3.22.37.1-1 How reproducible: 100% Steps to Reproduce: 1. Unpack the qpid-cpp-win package. 2. Compile the attached reproducer. 3. Start qpid broker and try to run the reproducer: csharp.example.helloworld.exe <broker_hostname> Actual results: SetContentObject() method raises the exception (see upper, please). Expected results: SetContentObject() method should fill in the message content from the given object.
Chuck, is there any workaround for this?
SetContentObject and GetContentObject fail to return the structured map and list object types. A workaround for this issue is to detect the message content type and then fetch the message into the proper container. static int Main(string[] args) { Dictionary<string, object> mapContent = new Dictionary<string, object>(); Message mapMsg = new Message(mapContent); Console.WriteLine("Map ContentType = {0}", mapMsg.ContentType); Collection<Object> colContent = new Collection<object>(); Message colMsg = new Message(colContent); Console.WriteLine("List ContentType = {0}", colMsg.ContentType); // Create message of some amqp type then discover that type // and retrieve the message content. Message someMsg = new Message("abc"); // string //Message someMsg = new Message(mapContent); // map //Message someMsg = new Message(colContent); // list if ("amqp/map" == someMsg.ContentType) { Dictionary<string, object> mapContentRcvd = new Dictionary<string, object>(); someMsg.GetContent(mapContentRcvd); } else if ("amqp/list" == someMsg.ContentType) { Collection<Object> colContentRcvd = new Collection<object>(); someMsg.GetContent(colContentRcvd); } else { string stringContentRcvd = ""; stringContentRcvd = someMsg.GetContent(); } return 0; }
What does Message.GetContent(someArg) do? There's no equivalent in the C++ api, and it's not documented in the .NET api. Is it an out param? If so, what is motivating us to have such things in .NET? They're not idiomatic. The workaround provided is mostly about extracting map and collection data, but the reported problem is *setting* it. If the workaround is as simple as "use the constructor", that's what we should say.
This is still an issue: Collection<Object> l = new Collection<Object>(); l.Add("hello"); l.Add("world"); msg.SetContentObject(l); The underlying type marshal code does not properly convert Collection (amqp/list) and Dictionary (amqp/map) at all. The SetContentObject code converts primitive objects like int and string only.
Commited upstream at r1615992
Retested on qpid-cpp-win-3.30.4.1-1: Now the SetContentObject method is able to set objects of System.Collections.Generic.Dictionary<T> or System.String types as message content. When I tried to set System.Collections.ObjectModel.Collection<T> type object as the message content the issue still persists, SetContentObject() raises the Exception.
Now the SetContentObject(object) method can accept System.Collections.ObjectModel.Collection<object> and System.Collections.Generic.Dictionary<string, object> types to fill in the message content. Verified on qpid-cpp-win-3.30.6.1-1 on Windows 7-x64, Windows 8-x64, Windows Server 2008-x64 and R2 and Windows Server 2012 R2. --> VERIFIED Thank you for the patch!
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-0805.html