You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@qpid.apache.org by tr...@apache.org on 2010/05/10 22:33:20 UTC
svn commit: r942892 [1/2] - in /qpid/trunk/qpid/cpp/bindings/qpid: ./
dotnet/ dotnet/examples/ dotnet/examples/csharp.direct.receiver/
dotnet/examples/csharp.direct.receiver/Properties/
dotnet/examples/csharp.direct.sender/ dotnet/examples/csharp.direc...
Author: tross
Date: Mon May 10 20:33:19 2010
New Revision: 942892
URL: http://svn.apache.org/viewvc?rev=942892&view=rev
Log:
QPID-2589 - Applied patch from Chuck Rolke.
Added:
qpid/trunk/qpid/cpp/bindings/qpid/
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/ReadMe.txt
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/Properties/
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/Properties/AssemblyInfo.cs
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/csharp.direct.receiver.cs
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/csharp.direct.receiver.csproj
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/Properties/
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/Properties/AssemblyInfo.cs
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/csharp.direct.sender.cs
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/csharp.direct.sender.csproj
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/org.apache.qpid.messaging.sln
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/AssemblyInfo.cpp
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Connection.cpp
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Connection.h
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Duration.cpp
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Duration.h
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Message.cpp
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Message.h
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/QpidMarshal.h
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/ReadMe.txt
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Receiver.cpp
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Receiver.h
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Sender.cpp
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Sender.h
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Session.cpp
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Session.h
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/app.rc
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/org.apache.qpid.messaging.vcproj
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/resource.h
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/messaging.test/
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/messaging.test/Properties/
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/messaging.test/Properties/AssemblyInfo.cs
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/messaging.test/messaging.test.cs
qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/messaging.test/messaging.test.csproj
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/ReadMe.txt
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/ReadMe.txt?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/ReadMe.txt (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/ReadMe.txt Mon May 10 20:33:19 2010
@@ -0,0 +1,33 @@
+Qpid.cpp.bindings.qpid.dotnet binding package.
+
+1. Features
+===========
+
+This binding package is a .NET Interop wrapper around the Qpid Messaging interface.
+It exposes the Messaging interface through a series of managed code classes that
+may be used by any .NET language.
+
+2. Prerequisites
+================
+
+1. A build of the Qpid C++ libraries is available.
+
+2. Refer to this library using environment variable QPID_BUILD_ROOT.
+
+ for example: SET QPID_BUILD_ROOT=D:\users\submitter\svn\qpid\cpp
+
+3. Building the solution
+========================
+
+1. Build the solution.
+
+4. Runing the examples
+======================
+
+CWIP
+
+5. Running the tests
+====================
+
+CWIP
+
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/Properties/AssemblyInfo.cs
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/Properties/AssemblyInfo.cs?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/Properties/AssemblyInfo.cs (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/Properties/AssemblyInfo.cs Mon May 10 20:33:19 2010
@@ -0,0 +1,36 @@
+using System.Reflection;
+using System.Runtime.CompilerServices;
+using System.Runtime.InteropServices;
+
+// General Information about an assembly is controlled through the following
+// set of attributes. Change these attribute values to modify the information
+// associated with an assembly.
+[assembly: AssemblyTitle("csharp.direct.receiver")]
+[assembly: AssemblyDescription("")]
+[assembly: AssemblyConfiguration("")]
+[assembly: AssemblyCompany("")]
+[assembly: AssemblyProduct("csharp.direct.receiver")]
+[assembly: AssemblyCopyright("Copyright © 2010")]
+[assembly: AssemblyTrademark("")]
+[assembly: AssemblyCulture("")]
+
+// Setting ComVisible to false makes the types in this assembly not visible
+// to COM components. If you need to access a type in this assembly from
+// COM, set the ComVisible attribute to true on that type.
+[assembly: ComVisible(false)]
+
+// The following GUID is for the ID of the typelib if this project is exposed to COM
+[assembly: Guid("c60b17ab-a82c-4edf-ba95-1e88bd4c3e75")]
+
+// Version information for an assembly consists of the following four values:
+//
+// Major Version
+// Minor Version
+// Build Number
+// Revision
+//
+// You can specify all the values or you can default the Build and Revision Numbers
+// by using the '*' as shown below:
+// [assembly: AssemblyVersion("1.0.*")]
+[assembly: AssemblyVersion("1.0.0.0")]
+[assembly: AssemblyFileVersion("1.0.0.0")]
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/csharp.direct.receiver.cs
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/csharp.direct.receiver.cs?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/csharp.direct.receiver.cs (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/csharp.direct.receiver.cs Mon May 10 20:33:19 2010
@@ -0,0 +1,57 @@
+using System;
+using System.Collections.Generic;
+using System.Linq;
+using System.Text;
+using org.apache.qpid.messaging;
+
+namespace CSharpDirect
+{
+ class Program
+ {
+ // Direct receiver example
+ //
+ // Receive 10 messages from localhost:5672, amq.direct/key
+ //
+ static void Main(string[] args)
+ {
+ String host = "localhost:5672";
+ String addr = "amq.direct/key";
+ int nMsg = 10;
+
+ Connection conn = new Connection(host);
+
+ conn.open();
+
+ if (!conn.isOpen())
+ {
+ Console.WriteLine("Failed to open connection to host : {0}", host);
+ }
+ else
+ {
+
+ Session sess = conn.createSession();
+
+ Duration dur = new Duration(1000 * 3600 * 24); // Wait one day
+
+ Receiver rcv = sess.createReceiver(addr);
+
+ Message msg = new Message("");
+
+ for (int i = 0; i < nMsg; i++)
+ {
+ try
+ {
+ Message msg2 = rcv.fetch(dur);
+ Console.WriteLine("Rcvd msg {0} : {1}", i, msg2.getContent());
+ }
+ catch (Exception e)
+ {
+ Console.WriteLine("Exception {0}.", e);
+ }
+ }
+
+ conn.close();
+ }
+ }
+ }
+}
\ No newline at end of file
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/csharp.direct.receiver.csproj
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/csharp.direct.receiver.csproj?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/csharp.direct.receiver.csproj (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.receiver/csharp.direct.receiver.csproj Mon May 10 20:33:19 2010
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+ <PropertyGroup>
+ <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
+ <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
+ <ProductVersion>9.0.30729</ProductVersion>
+ <SchemaVersion>2.0</SchemaVersion>
+ <ProjectGuid>{52F880E7-D677-4C91-8516-D679CE0F46A8}</ProjectGuid>
+ <OutputType>Exe</OutputType>
+ <AppDesignerFolder>Properties</AppDesignerFolder>
+ <RootNamespace>csharp.direct.receiver</RootNamespace>
+ <AssemblyName>csharp.direct.receiver</AssemblyName>
+ <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
+ <FileAlignment>512</FileAlignment>
+ </PropertyGroup>
+ <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
+ <DebugSymbols>true</DebugSymbols>
+ <DebugType>full</DebugType>
+ <Optimize>false</Optimize>
+ <OutputPath>bin\Debug\</OutputPath>
+ <DefineConstants>DEBUG;TRACE</DefineConstants>
+ <ErrorReport>prompt</ErrorReport>
+ <WarningLevel>4</WarningLevel>
+ </PropertyGroup>
+ <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
+ <DebugType>pdbonly</DebugType>
+ <Optimize>true</Optimize>
+ <OutputPath>bin\Release\</OutputPath>
+ <DefineConstants>TRACE</DefineConstants>
+ <ErrorReport>prompt</ErrorReport>
+ <WarningLevel>4</WarningLevel>
+ </PropertyGroup>
+ <ItemGroup>
+ <Reference Include="org.apache.qpid.messagingd, Version=1.0.3779.23054, Culture=neutral, PublicKeyToken=679e1f50b62dbace, processorArchitecture=x86">
+ <SpecificVersion>False</SpecificVersion>
+ <HintPath>..\..\bin\Debug\org.apache.qpid.messagingd.dll</HintPath>
+ </Reference>
+ <Reference Include="System" />
+ <Reference Include="System.Core">
+ <RequiredTargetFramework>3.5</RequiredTargetFramework>
+ </Reference>
+ <Reference Include="System.Xml.Linq">
+ <RequiredTargetFramework>3.5</RequiredTargetFramework>
+ </Reference>
+ <Reference Include="System.Data.DataSetExtensions">
+ <RequiredTargetFramework>3.5</RequiredTargetFramework>
+ </Reference>
+ <Reference Include="System.Data" />
+ <Reference Include="System.Xml" />
+ </ItemGroup>
+ <ItemGroup>
+ <Compile Include="csharp.direct.receiver.cs" />
+ <Compile Include="Properties\AssemblyInfo.cs" />
+ </ItemGroup>
+ <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
+ <!-- To modify your build process, add your task inside one of the targets below and uncomment it.
+ Other similar extension points exist, see Microsoft.Common.targets.
+ <Target Name="BeforeBuild">
+ </Target>
+ <Target Name="AfterBuild">
+ </Target>
+ -->
+</Project>
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/Properties/AssemblyInfo.cs
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/Properties/AssemblyInfo.cs?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/Properties/AssemblyInfo.cs (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/Properties/AssemblyInfo.cs Mon May 10 20:33:19 2010
@@ -0,0 +1,36 @@
+using System.Reflection;
+using System.Runtime.CompilerServices;
+using System.Runtime.InteropServices;
+
+// General Information about an assembly is controlled through the following
+// set of attributes. Change these attribute values to modify the information
+// associated with an assembly.
+[assembly: AssemblyTitle("csharp.direct.sender")]
+[assembly: AssemblyDescription("")]
+[assembly: AssemblyConfiguration("")]
+[assembly: AssemblyCompany("")]
+[assembly: AssemblyProduct("csharp.direct.sender")]
+[assembly: AssemblyCopyright("Copyright © 2010")]
+[assembly: AssemblyTrademark("")]
+[assembly: AssemblyCulture("")]
+
+// Setting ComVisible to false makes the types in this assembly not visible
+// to COM components. If you need to access a type in this assembly from
+// COM, set the ComVisible attribute to true on that type.
+[assembly: ComVisible(false)]
+
+// The following GUID is for the ID of the typelib if this project is exposed to COM
+[assembly: Guid("19ce67e4-db90-4480-88c4-3721f47634c7")]
+
+// Version information for an assembly consists of the following four values:
+//
+// Major Version
+// Minor Version
+// Build Number
+// Revision
+//
+// You can specify all the values or you can default the Build and Revision Numbers
+// by using the '*' as shown below:
+// [assembly: AssemblyVersion("1.0.*")]
+[assembly: AssemblyVersion("1.0.0.0")]
+[assembly: AssemblyFileVersion("1.0.0.0")]
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/csharp.direct.sender.cs
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/csharp.direct.sender.cs?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/csharp.direct.sender.cs (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/csharp.direct.sender.cs Mon May 10 20:33:19 2010
@@ -0,0 +1,42 @@
+using System;
+using System.Collections.Generic;
+using System.Linq;
+using System.Text;
+using org.apache.qpid.messaging;
+
+namespace csharp.direct.sender
+{
+ class Program
+ {
+ static void Main(string[] args)
+ {
+ String host = "localhost:5672";
+ String addr = "amq.direct/key";
+ int nMsg = 10;
+
+ Connection conn = new Connection(host);
+
+ conn.open();
+
+ if (!conn.isOpen())
+ {
+ Console.WriteLine("Failed to open connection to host : {0}", host);
+ }
+ else
+ {
+ Session sess = conn.createSession();
+
+ Sender snd = sess.createSender(addr);
+
+ for (int i = 0; i < nMsg; i++)
+ {
+ Message msg = new Message(String.Format("Test Message {0}", i));
+
+ snd.send(msg);
+ }
+
+ conn.close();
+ }
+ }
+ }
+}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/csharp.direct.sender.csproj
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/csharp.direct.sender.csproj?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/csharp.direct.sender.csproj (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/examples/csharp.direct.sender/csharp.direct.sender.csproj Mon May 10 20:33:19 2010
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+ <PropertyGroup>
+ <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
+ <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
+ <ProductVersion>9.0.30729</ProductVersion>
+ <SchemaVersion>2.0</SchemaVersion>
+ <ProjectGuid>{7B71CE78-8E78-4632-ADBE-F4D5DFAE0068}</ProjectGuid>
+ <OutputType>Exe</OutputType>
+ <AppDesignerFolder>Properties</AppDesignerFolder>
+ <RootNamespace>csharp.direct.sender</RootNamespace>
+ <AssemblyName>csharp.direct.sender</AssemblyName>
+ <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
+ <FileAlignment>512</FileAlignment>
+ </PropertyGroup>
+ <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
+ <DebugSymbols>true</DebugSymbols>
+ <DebugType>full</DebugType>
+ <Optimize>false</Optimize>
+ <OutputPath>bin\Debug\</OutputPath>
+ <DefineConstants>DEBUG;TRACE</DefineConstants>
+ <ErrorReport>prompt</ErrorReport>
+ <WarningLevel>4</WarningLevel>
+ </PropertyGroup>
+ <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
+ <DebugType>pdbonly</DebugType>
+ <Optimize>true</Optimize>
+ <OutputPath>bin\Release\</OutputPath>
+ <DefineConstants>TRACE</DefineConstants>
+ <ErrorReport>prompt</ErrorReport>
+ <WarningLevel>4</WarningLevel>
+ </PropertyGroup>
+ <ItemGroup>
+ <Reference Include="org.apache.qpid.messagingd, Version=1.0.3779.23054, Culture=neutral, PublicKeyToken=679e1f50b62dbace, processorArchitecture=x86">
+ <SpecificVersion>False</SpecificVersion>
+ <HintPath>..\..\bin\Debug\org.apache.qpid.messagingd.dll</HintPath>
+ </Reference>
+ <Reference Include="System" />
+ <Reference Include="System.Core">
+ <RequiredTargetFramework>3.5</RequiredTargetFramework>
+ </Reference>
+ <Reference Include="System.Xml.Linq">
+ <RequiredTargetFramework>3.5</RequiredTargetFramework>
+ </Reference>
+ <Reference Include="System.Data.DataSetExtensions">
+ <RequiredTargetFramework>3.5</RequiredTargetFramework>
+ </Reference>
+ <Reference Include="System.Data" />
+ <Reference Include="System.Xml" />
+ </ItemGroup>
+ <ItemGroup>
+ <Compile Include="csharp.direct.sender.cs" />
+ <Compile Include="Properties\AssemblyInfo.cs" />
+ </ItemGroup>
+ <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
+ <!-- To modify your build process, add your task inside one of the targets below and uncomment it.
+ Other similar extension points exist, see Microsoft.Common.targets.
+ <Target Name="BeforeBuild">
+ </Target>
+ <Target Name="AfterBuild">
+ </Target>
+ -->
+</Project>
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/org.apache.qpid.messaging.sln
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/org.apache.qpid.messaging.sln?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/org.apache.qpid.messaging.sln (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/org.apache.qpid.messaging.sln Mon May 10 20:33:19 2010
@@ -0,0 +1,89 @@
+Microsoft Visual Studio Solution File, Format Version 10.00
+# Visual Studio 2008
+Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "org.apache.qpid.messaging", "src\org.apache.qpid.messaging.vcproj", "{AA5A3B83-5F98-406D-A01C-5A921467A57D}"
+EndProject
+Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Examples", "Examples", "{34C477FB-B0CC-4AB9-A346-EA7B055469AC}"
+EndProject
+Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Direct", "Direct", "{DE58D329-10DC-4C8D-9EFA-230A57314089}"
+EndProject
+Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Pub-Sub", "Pub-Sub", "{878FDDF8-A870-41D6-9E36-0A050EC5ACAB}"
+EndProject
+Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "csharp.direct.sender", "examples\csharp.direct.sender\csharp.direct.sender.csproj", "{7B71CE78-8E78-4632-ADBE-F4D5DFAE0068}"
+ ProjectSection(ProjectDependencies) = postProject
+ {AA5A3B83-5F98-406D-A01C-5A921467A57D} = {AA5A3B83-5F98-406D-A01C-5A921467A57D}
+ EndProjectSection
+EndProject
+Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "csharp.direct.receiver", "examples\csharp.direct.receiver\csharp.direct.receiver.csproj", "{52F880E7-D677-4C91-8516-D679CE0F46A8}"
+ ProjectSection(ProjectDependencies) = postProject
+ {AA5A3B83-5F98-406D-A01C-5A921467A57D} = {AA5A3B83-5F98-406D-A01C-5A921467A57D}
+ EndProjectSection
+EndProject
+Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Test", "Test", "{39E9D1BF-3A0B-4D86-BF6B-F463E1A2245A}"
+EndProject
+Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "messaging.test", "test\messaging.test\messaging.test.csproj", "{AF2FBC78-266C-430C-BC29-9477AB596A36}"
+ ProjectSection(ProjectDependencies) = postProject
+ {AA5A3B83-5F98-406D-A01C-5A921467A57D} = {AA5A3B83-5F98-406D-A01C-5A921467A57D}
+ EndProjectSection
+EndProject
+Global
+ GlobalSection(SolutionConfigurationPlatforms) = preSolution
+ Debug|Any CPU = Debug|Any CPU
+ Debug|Mixed Platforms = Debug|Mixed Platforms
+ Debug|Win32 = Debug|Win32
+ Release|Any CPU = Release|Any CPU
+ Release|Mixed Platforms = Release|Mixed Platforms
+ Release|Win32 = Release|Win32
+ EndGlobalSection
+ GlobalSection(ProjectConfigurationPlatforms) = postSolution
+ {AA5A3B83-5F98-406D-A01C-5A921467A57D}.Debug|Any CPU.ActiveCfg = Debug|Win32
+ {AA5A3B83-5F98-406D-A01C-5A921467A57D}.Debug|Mixed Platforms.ActiveCfg = Debug|Win32
+ {AA5A3B83-5F98-406D-A01C-5A921467A57D}.Debug|Mixed Platforms.Build.0 = Debug|Win32
+ {AA5A3B83-5F98-406D-A01C-5A921467A57D}.Debug|Win32.ActiveCfg = Debug|Win32
+ {AA5A3B83-5F98-406D-A01C-5A921467A57D}.Debug|Win32.Build.0 = Debug|Win32
+ {AA5A3B83-5F98-406D-A01C-5A921467A57D}.Release|Any CPU.ActiveCfg = Release|Win32
+ {AA5A3B83-5F98-406D-A01C-5A921467A57D}.Release|Mixed Platforms.ActiveCfg = Release|Win32
+ {AA5A3B83-5F98-406D-A01C-5A921467A57D}.Release|Mixed Platforms.Build.0 = Release|Win32
+ {AA5A3B83-5F98-406D-A01C-5A921467A57D}.Release|Win32.ActiveCfg = Release|Win32
+ {AA5A3B83-5F98-406D-A01C-5A921467A57D}.Release|Win32.Build.0 = Release|Win32
+ {7B71CE78-8E78-4632-ADBE-F4D5DFAE0068}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
+ {7B71CE78-8E78-4632-ADBE-F4D5DFAE0068}.Debug|Any CPU.Build.0 = Debug|Any CPU
+ {7B71CE78-8E78-4632-ADBE-F4D5DFAE0068}.Debug|Mixed Platforms.ActiveCfg = Debug|Any CPU
+ {7B71CE78-8E78-4632-ADBE-F4D5DFAE0068}.Debug|Mixed Platforms.Build.0 = Debug|Any CPU
+ {7B71CE78-8E78-4632-ADBE-F4D5DFAE0068}.Debug|Win32.ActiveCfg = Debug|Any CPU
+ {7B71CE78-8E78-4632-ADBE-F4D5DFAE0068}.Release|Any CPU.ActiveCfg = Release|Any CPU
+ {7B71CE78-8E78-4632-ADBE-F4D5DFAE0068}.Release|Any CPU.Build.0 = Release|Any CPU
+ {7B71CE78-8E78-4632-ADBE-F4D5DFAE0068}.Release|Mixed Platforms.ActiveCfg = Release|Any CPU
+ {7B71CE78-8E78-4632-ADBE-F4D5DFAE0068}.Release|Mixed Platforms.Build.0 = Release|Any CPU
+ {7B71CE78-8E78-4632-ADBE-F4D5DFAE0068}.Release|Win32.ActiveCfg = Release|Any CPU
+ {52F880E7-D677-4C91-8516-D679CE0F46A8}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
+ {52F880E7-D677-4C91-8516-D679CE0F46A8}.Debug|Any CPU.Build.0 = Debug|Any CPU
+ {52F880E7-D677-4C91-8516-D679CE0F46A8}.Debug|Mixed Platforms.ActiveCfg = Debug|Any CPU
+ {52F880E7-D677-4C91-8516-D679CE0F46A8}.Debug|Mixed Platforms.Build.0 = Debug|Any CPU
+ {52F880E7-D677-4C91-8516-D679CE0F46A8}.Debug|Win32.ActiveCfg = Debug|Any CPU
+ {52F880E7-D677-4C91-8516-D679CE0F46A8}.Release|Any CPU.ActiveCfg = Release|Any CPU
+ {52F880E7-D677-4C91-8516-D679CE0F46A8}.Release|Any CPU.Build.0 = Release|Any CPU
+ {52F880E7-D677-4C91-8516-D679CE0F46A8}.Release|Mixed Platforms.ActiveCfg = Release|Any CPU
+ {52F880E7-D677-4C91-8516-D679CE0F46A8}.Release|Mixed Platforms.Build.0 = Release|Any CPU
+ {52F880E7-D677-4C91-8516-D679CE0F46A8}.Release|Win32.ActiveCfg = Release|Any CPU
+ {AF2FBC78-266C-430C-BC29-9477AB596A36}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
+ {AF2FBC78-266C-430C-BC29-9477AB596A36}.Debug|Any CPU.Build.0 = Debug|Any CPU
+ {AF2FBC78-266C-430C-BC29-9477AB596A36}.Debug|Mixed Platforms.ActiveCfg = Debug|Any CPU
+ {AF2FBC78-266C-430C-BC29-9477AB596A36}.Debug|Mixed Platforms.Build.0 = Debug|Any CPU
+ {AF2FBC78-266C-430C-BC29-9477AB596A36}.Debug|Win32.ActiveCfg = Debug|Any CPU
+ {AF2FBC78-266C-430C-BC29-9477AB596A36}.Release|Any CPU.ActiveCfg = Release|Any CPU
+ {AF2FBC78-266C-430C-BC29-9477AB596A36}.Release|Any CPU.Build.0 = Release|Any CPU
+ {AF2FBC78-266C-430C-BC29-9477AB596A36}.Release|Mixed Platforms.ActiveCfg = Release|Any CPU
+ {AF2FBC78-266C-430C-BC29-9477AB596A36}.Release|Mixed Platforms.Build.0 = Release|Any CPU
+ {AF2FBC78-266C-430C-BC29-9477AB596A36}.Release|Win32.ActiveCfg = Release|Any CPU
+ EndGlobalSection
+ GlobalSection(SolutionProperties) = preSolution
+ HideSolutionNode = FALSE
+ EndGlobalSection
+ GlobalSection(NestedProjects) = preSolution
+ {DE58D329-10DC-4C8D-9EFA-230A57314089} = {34C477FB-B0CC-4AB9-A346-EA7B055469AC}
+ {878FDDF8-A870-41D6-9E36-0A050EC5ACAB} = {34C477FB-B0CC-4AB9-A346-EA7B055469AC}
+ {7B71CE78-8E78-4632-ADBE-F4D5DFAE0068} = {DE58D329-10DC-4C8D-9EFA-230A57314089}
+ {52F880E7-D677-4C91-8516-D679CE0F46A8} = {DE58D329-10DC-4C8D-9EFA-230A57314089}
+ {AF2FBC78-266C-430C-BC29-9477AB596A36} = {39E9D1BF-3A0B-4D86-BF6B-F463E1A2245A}
+ EndGlobalSection
+EndGlobal
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/AssemblyInfo.cpp
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/AssemblyInfo.cpp?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/AssemblyInfo.cpp (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/AssemblyInfo.cpp Mon May 10 20:33:19 2010
@@ -0,0 +1,57 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+
+using namespace System;
+using namespace System::Reflection;
+using namespace System::Runtime::CompilerServices;
+using namespace System::Runtime::InteropServices;
+using namespace System::Security::Permissions;
+
+//
+// General Information about an assembly is controlled through the following
+// set of attributes. Change these attribute values to modify the information
+// associated with an assembly.
+//
+[assembly:AssemblyTitleAttribute("org.apache.qpid.messaging")];
+[assembly:AssemblyDescriptionAttribute("")];
+[assembly:AssemblyConfigurationAttribute("")];
+[assembly:AssemblyCompanyAttribute("")];
+[assembly:AssemblyProductAttribute("org.apache.qpid.messaging")];
+[assembly:AssemblyCopyrightAttribute("Copyright (c) 2010")];
+[assembly:AssemblyTrademarkAttribute("")];
+[assembly:AssemblyCultureAttribute("")];
+
+//
+// Version information for an assembly consists of the following four values:
+//
+// Major Version
+// Minor Version
+// Build Number
+// Revision
+//
+// You can specify all the value or you can default the Revision and Build Numbers
+// by using the '*' as shown below:
+
+[assembly:AssemblyVersionAttribute("1.0.*")];
+
+[assembly:ComVisible(false)];
+
+[assembly:CLSCompliantAttribute(true)];
+
+[assembly:SecurityPermission(SecurityAction::RequestMinimum, UnmanagedCode = true)];
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Connection.cpp
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Connection.cpp?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Connection.cpp (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Connection.cpp Mon May 10 20:33:19 2010
@@ -0,0 +1,115 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+
+#include <windows.h>
+#include <msclr\lock.h>
+#include <oletx2xa.h>
+#include <string>
+#include <limits>
+
+#include "qpid/messaging/Connection.h"
+#include "qpid/messaging/Session.h"
+
+#include "QpidMarshal.h"
+#include "Connection.h"
+#include "Session.h"
+
+namespace org {
+namespace apache {
+namespace qpid {
+namespace messaging {
+
+ /// <summary>
+ /// Connection is a managed wrapper for a qpid::messaging::Connection
+ /// </summary>
+
+ // Public constructor
+ Connection::Connection(System::String ^ url) :
+ connectionp(new ::qpid::messaging::Connection(QpidMarshal::ToNative(url)))
+ {
+ }
+
+ Connection::Connection(System::String ^ url, System::String ^ options) :
+ connectionp(new ::qpid::messaging::Connection(QpidMarshal::ToNative(url),
+ QpidMarshal::ToNative(options)))
+ {
+ }
+
+
+ // Destructor
+ Connection::~Connection()
+ {
+ Cleanup();
+ }
+
+
+ // Finalizer
+ Connection::!Connection()
+ {
+ Cleanup();
+ }
+
+
+ // Destroys kept object
+ // TODO: add lock
+ void Connection::Cleanup()
+ {
+ if (NULL != connectionp)
+ {
+ delete connectionp;
+ connectionp = NULL;
+ }
+ }
+
+ Session ^ Connection::createSession()
+ {
+ return createSession("");
+ }
+
+
+ Session ^ Connection::createSession(System::String ^ name)
+ {
+ // allocate native session
+ ::qpid::messaging::Session * sessionp = new ::qpid::messaging::Session;
+
+ // create native session
+ *sessionp = connectionp->createSession(QpidMarshal::ToNative(name));
+
+ // create managed session
+ Session ^ newSession = gcnew Session(sessionp, this);
+
+ return newSession;
+ }
+
+
+ void Connection::open()
+ {
+ connectionp->open();
+ }
+
+ bool Connection::isOpen()
+ {
+ return connectionp->isOpen();
+ }
+
+ void Connection::close()
+ {
+ connectionp->close();
+ }
+}}}}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Connection.h
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Connection.h?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Connection.h (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Connection.h Mon May 10 20:33:19 2010
@@ -0,0 +1,63 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+
+#pragma once
+
+#include <windows.h>
+#include <msclr\lock.h>
+#include <oletx2xa.h>
+#include <string>
+#include <limits>
+
+#include "qpid/messaging/Connection.h"
+#include "qpid/messaging/Session.h"
+
+namespace org {
+namespace apache {
+namespace qpid {
+namespace messaging {
+
+ /// <summary>
+ /// Connection is a managed wrapper for a qpid::messaging::Connection
+ /// </summary>
+
+ ref class Session;
+
+ public ref class Connection
+ {
+ private:
+ // The kept object in the Messaging C++ DLL
+ ::qpid::messaging::Connection * connectionp;
+
+ // Kept object deletion code
+ void Cleanup();
+
+ public:
+ Connection(System::String ^ url);
+ Connection(System::String ^ url, System::String ^ options);
+ ~Connection();
+ !Connection();
+
+ Session ^ createSession();
+ Session ^ createSession(System::String ^ name);
+ void open();
+ bool isOpen();
+ void close();
+ };
+}}}}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Duration.cpp
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Duration.cpp?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Duration.cpp (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Duration.cpp Mon May 10 20:33:19 2010
@@ -0,0 +1,107 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+
+#include <windows.h>
+#include <msclr\lock.h>
+#include <oletx2xa.h>
+#include <string>
+#include <limits>
+
+#include "qpid/messaging/Duration.h"
+
+#include "Duration.h"
+
+namespace org {
+namespace apache {
+namespace qpid {
+namespace messaging {
+
+ /// <summary>
+ /// Duration is a time interval in milliseconds.
+ /// It is a managed wrapper for a ::qpid::messaging::Duration
+ /// </summary>
+
+ // Public constructor
+ Duration::Duration(System::UInt64 milliseconds) :
+ durationp(new ::qpid::messaging::Duration(milliseconds))
+ {
+ }
+
+ // Private experimental constructor
+ Duration::Duration(const ::qpid::messaging::Duration * d) :
+ durationp(d)
+ {
+ }
+
+
+ // Destructor
+ Duration::~Duration()
+ {
+ Cleanup();
+ }
+
+
+ // Finalizer
+ Duration::!Duration()
+ {
+ Cleanup();
+ }
+
+
+ // Returns the value from kept object
+ System::UInt64 Duration::getMilliseconds()
+ {
+ return durationp->getMilliseconds();
+ }
+
+
+ // Destroys kept object
+ // TODO: add lock
+ void Duration::Cleanup()
+ {
+ if (NULL != durationp)
+ {
+ delete durationp;
+ durationp = NULL;
+ }
+ }
+
+ // Return value(s) for constant durations
+ // NOTE: These return the duration mS and not a Duration
+ // object like the C++ code gets.
+ System::UInt64 Duration::FOREVER()
+ {
+ return ::qpid::messaging::Duration::FOREVER.getMilliseconds();
+ }
+
+ System::UInt64 Duration::IMMEDIATE()
+ {
+ return ::qpid::messaging::Duration::IMMEDIATE.getMilliseconds();
+ }
+
+ System::UInt64 Duration::SECOND()
+ {
+ return ::qpid::messaging::Duration::SECOND.getMilliseconds();
+ }
+
+ System::UInt64 Duration::MINUTE()
+ {
+ return ::qpid::messaging::Duration::MINUTE.getMilliseconds();
+ }
+}}}}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Duration.h
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Duration.h?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Duration.h (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Duration.h Mon May 10 20:33:19 2010
@@ -0,0 +1,67 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+
+#pragma once
+
+#include <windows.h>
+#include <msclr\lock.h>
+#include <oletx2xa.h>
+#include <string>
+#include <limits>
+
+#include "qpid/messaging/Duration.h"
+
+namespace org {
+namespace apache {
+namespace qpid {
+namespace messaging {
+
+ /// <summary>
+ /// Duration is a time interval in milliseconds.
+ /// It is a managed wrapper for a ::qpid::messaging::Duration
+ /// </summary>
+
+ public ref class Duration
+ {
+ private:
+ // Experimental constructor
+ Duration(const ::qpid::messaging::Duration *);
+
+ // Kept object deletion code
+ void Cleanup();
+
+ public:
+ Duration(System::UInt64 milliseconds);
+ ~Duration();
+ !Duration();
+
+ // The kept object in the Messaging C++ DLL
+ const ::qpid::messaging::Duration * durationp;
+
+ System::UInt64 getMilliseconds();
+
+ // Return value(s) for constant durations
+ // NOTE: These return the duration mS and not a Duration
+ // object like the C++ code gets.
+ System::UInt64 FOREVER();
+ System::UInt64 IMMEDIATE();
+ System::UInt64 SECOND();
+ System::UInt64 MINUTE();
+ };
+}}}}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Message.cpp
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Message.cpp?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Message.cpp (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Message.cpp Mon May 10 20:33:19 2010
@@ -0,0 +1,202 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+
+#include <windows.h>
+#include <msclr\lock.h>
+#include <oletx2xa.h>
+#include <string>
+#include <limits>
+
+#include "qpid/messaging/Message.h"
+
+#include "QpidMarshal.h"
+#include "Message.h"
+
+namespace org {
+namespace apache {
+namespace qpid {
+namespace messaging {
+
+ /// <summary>
+ /// Message is a managed wrapper for a ::qpid::messaging::Message
+ /// </summary>
+
+ // This constructor is used to create a message from bytes to put into the message
+ Message::Message(System::String ^ bytes) :
+ messagep(new ::qpid::messaging::Message(QpidMarshal::ToNative(bytes)))
+ {
+ }
+
+ // This constructor creates a message from a native received message
+ Message::Message(::qpid::messaging::Message * msgp) :
+ messagep(msgp)
+ {
+ }
+
+ // Destructor
+ Message::~Message()
+ {
+ Cleanup();
+ }
+
+
+ // Finalizer
+ Message::!Message()
+ {
+ Cleanup();
+ }
+
+ // Copy constructor
+ Message::Message(const Message % rhs)
+ {
+ messagep = rhs.messagep;
+ }
+
+ // Destroys kept object
+ // TODO: add lock
+ void Message::Cleanup()
+ {
+ if (NULL != messagep)
+ {
+ delete messagep;
+ messagep = NULL;
+ }
+ }
+
+ //void Message::setReplyTo(System::String ^ address)
+ //{
+ // messagep->setReplyTo(QpidMarshal::ToNative(address));
+ //}
+
+ //System::String ^ Message::getReplyTo()
+ //{
+ // return gcnew String(messagep->getReplyTo().c_str());
+ //}
+
+
+ void Message::setSubject(System::String ^ subject)
+ {
+ messagep->setSubject(QpidMarshal::ToNative(subject));
+ }
+
+ System::String ^ Message::getSubject()
+ {
+ return gcnew String(messagep->getSubject().c_str());
+ }
+
+
+ void Message::setContentType(System::String ^ ct)
+ {
+ messagep->setContentType(QpidMarshal::ToNative(ct));
+ }
+
+ System::String ^ Message::getContentType()
+ {
+ return gcnew String(messagep->getContentType().c_str());
+ }
+
+
+ void Message::setMessageId(System::String ^ mId)
+ {
+ messagep->setMessageId(QpidMarshal::ToNative(mId));
+ }
+
+ System::String ^ Message::getMessageId()
+ {
+ return gcnew String(messagep->getMessageId().c_str());
+ }
+
+
+ void Message::setUserId(System::String ^ uId)
+ {
+ messagep->setUserId(QpidMarshal::ToNative(uId));
+ }
+
+ System::String ^ Message::getUserId()
+ {
+ return gcnew String(messagep->getUserId().c_str());
+ }
+
+
+ void Message::setCorrelationId(System::String ^ cId)
+ {
+ messagep->setCorrelationId(QpidMarshal::ToNative(cId));
+ }
+
+ System::String ^ Message::getCorrelationId()
+ {
+ return gcnew String(messagep->getCorrelationId().c_str());
+ }
+
+
+ void Message::setPriority(unsigned char priority)
+ {
+ messagep->setPriority(priority);
+ }
+
+ unsigned char Message::getPriority()
+ {
+ return messagep->getPriority();
+ }
+
+
+ //void setTtl(Duration ttl);
+ //Duration getTtl();
+
+ void Message::setDurable(bool durable)
+ {
+ messagep->setDurable(durable);
+ }
+
+ bool Message::getDurable()
+ {
+ return messagep->getDurable();
+ }
+
+
+ bool Message::getRedelivered()
+ {
+ return messagep->getRedelivered();
+ }
+
+ void Message::setRedelivered(bool redelivered)
+ {
+ messagep->setRedelivered(redelivered);
+ }
+
+
+ //System::String ^ Message::getProperties()
+ //{
+ // pqid::types::Variant::Map * mapp = new
+ // return gcnew String(messagep->getReplyTo().c_str());
+ //}
+
+
+ void Message::setContent(System::String ^ content)
+ {
+ messagep->setContent(QpidMarshal::ToNative(content));
+ }
+
+
+ System::String ^ Message::getContent()
+ {
+ return gcnew String(messagep->getContent().c_str());
+ }
+
+}}}}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Message.h
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Message.h?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Message.h (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Message.h Mon May 10 20:33:19 2010
@@ -0,0 +1,92 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+#pragma once
+
+#include <windows.h>
+#include <msclr\lock.h>
+#include <oletx2xa.h>
+#include <string>
+#include <limits>
+
+#include "qpid/messaging/Message.h"
+
+namespace org {
+namespace apache {
+namespace qpid {
+namespace messaging {
+
+ /// <summary>
+ /// Message is a managed wrapper for a ::qpid::messaging::Message
+ /// </summary>
+
+
+ public ref class Message
+ {
+
+ private:
+ // Kept object deletion code
+ void Cleanup();
+
+ public:
+ Message(System::String ^ bytes);
+ Message(::qpid::messaging::Message * msgp);
+ ~Message();
+ !Message();
+ Message(const Message % rhs);
+
+ // The kept object in the Messaging C++ DLL
+ ::qpid::messaging::Message * messagep;
+
+ //void setReplyTo(System::String ^ address);
+ //System::String ^ getReplyTo();
+
+ void setSubject(System::String ^ subject);
+ System::String ^ getSubject();
+
+ void setContentType(System::String ^ ct);
+ System::String ^ getContentType();
+
+ void setMessageId(System::String ^ mId);
+ System::String ^ getMessageId();
+
+ void setUserId(System::String ^ uId);
+ System::String ^ getUserId();
+
+ void setCorrelationId(System::String ^ cId);
+ System::String ^ getCorrelationId();
+
+ void setPriority(unsigned char priority);
+ unsigned char getPriority();
+
+ //void setTtl(Duration ttl);
+ //Duration getTtl();
+
+ void setDurable(bool durable);
+ bool getDurable();
+
+ bool getRedelivered();
+ void setRedelivered(bool redelivered);
+
+ //System::String ^ getProperties();
+
+ void setContent(System::String ^ content);
+
+ System::String ^ getContent();
+ };
+}}}}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/QpidMarshal.h
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/QpidMarshal.h?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/QpidMarshal.h (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/QpidMarshal.h Mon May 10 20:33:19 2010
@@ -0,0 +1,61 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+
+#pragma once
+
+using namespace System;
+using namespace System::Text;
+
+namespace org {
+namespace apache {
+namespace qpid {
+namespace messaging {
+
+
+
+// Helper functions for marshaling.
+
+private ref class QpidMarshal
+{
+public:
+
+ /// <summary>
+ /// Convert managed String into native UTF8-encoded string
+ /// </summary>
+
+ static std::string ToNative (System::String^ managed)
+ {
+ if (managed->Length == 0)
+ {
+ return std::string();
+ }
+
+ array<unsigned char>^ mbytes = Encoding::UTF8->GetBytes(managed);
+ if (mbytes->Length == 0)
+ {
+ return std::string();
+ }
+
+ pin_ptr<unsigned char> pinnedBuf = &mbytes[0];
+ std::string native((char *) pinnedBuf, mbytes->Length);
+ return native;
+ }
+};
+
+}}}}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/ReadMe.txt
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/ReadMe.txt?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/ReadMe.txt (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/ReadMe.txt Mon May 10 20:33:19 2010
@@ -0,0 +1,40 @@
+========================================================================
+ DYNAMIC LINK LIBRARY : org.apache.qpid.messaging Project Overview
+========================================================================
+
+AppWizard has created this org.apache.qpid.messaging DLL for you.
+
+This file contains a summary of what you will find in each of the files that
+make up your org.apache.qpid.messaging application.
+
+org.apache.qpid.messaging.vcproj
+ This is the main project file for VC++ projects generated using an Application Wizard.
+ It contains information about the version of Visual C++ that generated the file, and
+ information about the platforms, configurations, and project features selected with the
+ Application Wizard.
+
+Connection.[cpp h]
+Duration.[cpp h]
+Message.[cpp h]
+Receiver.[cpp h]
+Sender.[cpp h]
+Session.[cpp h]
+ Managed code Interop layer modules to provide access to functions exported by
+ qpidcommon.dll.
+
+AssemblyInfo.cpp
+ Contains custom attributes for modifying assembly metadata.
+
+/////////////////////////////////////////////////////////////////////////////
+Other notes:
+
+AppWizard uses "TODO:" to indicate parts of the source code you
+should add to or customize.
+
+Current TODOs include:
+
+ * Add locking as needed
+ * Add remaining modules and methods
+ * Capture and repackage exceptions emitted from messaging DLLs
+
+/////////////////////////////////////////////////////////////////////////////
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Receiver.cpp
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Receiver.cpp?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Receiver.cpp (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Receiver.cpp Mon May 10 20:33:19 2010
@@ -0,0 +1,164 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+
+#include <windows.h>
+#include <msclr\lock.h>
+#include <oletx2xa.h>
+#include <string>
+#include <limits>
+
+#include "qpid/messaging/Receiver.h"
+#include "qpid/messaging/Session.h"
+#include "qpid/messaging/Message.h"
+
+#include "Receiver.h"
+#include "Session.h"
+#include "Message.h"
+#include "Duration.h"
+
+namespace org {
+namespace apache {
+namespace qpid {
+namespace messaging {
+
+ /// <summary>
+ /// Receiver is a managed wrapper for a ::qpid::messaging::Receiver
+ /// </summary>
+
+ Receiver::Receiver(::qpid::messaging::Receiver * r,
+ Session ^ sessRef) :
+ receiverp(r),
+ parentSession(sessRef)
+ {
+ }
+
+
+ // Destructor
+ Receiver::~Receiver()
+ {
+ Cleanup();
+ }
+
+
+ // Finalizer
+ Receiver::!Receiver()
+ {
+ Cleanup();
+ }
+
+
+ // Copy constructor
+ Receiver::Receiver(const Receiver ^ rhs)
+ {
+ receiverp = rhs->receiverp;
+ parentSession = rhs->parentSession;
+ }
+
+
+ // Destroys kept object
+ // TODO: add lock
+ void Receiver::Cleanup()
+ {
+ if (NULL != receiverp)
+ {
+ delete receiverp;
+ receiverp = NULL;
+ }
+ }
+
+ bool Receiver::get(Message ^ mmsgp)
+ {
+ return receiverp->Receiver::get(*((*mmsgp).messagep));
+ }
+
+ bool Receiver::get(Message ^ mmsgp, Duration ^ durationp)
+ {
+ return receiverp->Receiver::get(*((*mmsgp).messagep),
+ *((*durationp).durationp));
+ }
+
+ Message ^ Receiver::get(Duration ^ durationp)
+ {
+ // allocate a message
+ ::qpid::messaging::Message * msgp = new ::qpid::messaging::Message;
+
+ // get the message
+ *msgp = receiverp->::qpid::messaging::Receiver::get(*((*durationp).durationp));
+
+ // create new managed message with received message embedded in it
+ Message ^ newMessage = gcnew Message(msgp);
+
+ return newMessage;
+ }
+
+ bool Receiver::fetch(Message ^ mmsgp)
+ {
+ return receiverp->::qpid::messaging::Receiver::fetch(*((*mmsgp).messagep));
+ }
+
+ bool Receiver::fetch(Message ^ mmsgp, Duration ^ durationp)
+ {
+ return receiverp->::qpid::messaging::Receiver::fetch(*((*mmsgp).messagep),
+ *((*durationp).durationp));
+ }
+
+ Message ^ Receiver::fetch(Duration ^ durationp)
+ {
+ // allocate a message
+ ::qpid::messaging::Message * msgp = new ::qpid::messaging::Message;
+
+ // get the message
+ *msgp = receiverp->::qpid::messaging::Receiver::fetch(*((*durationp).durationp));
+
+ // create new managed message with received message embedded in it
+ Message ^ newMessage = gcnew Message(msgp);
+
+ return newMessage;
+ }
+
+ System::UInt32 Receiver::getCapacity()
+ {
+ return receiverp->getCapacity();
+ }
+
+ System::UInt32 Receiver::getAvailable()
+ {
+ return receiverp->getAvailable();
+ }
+
+ System::UInt32 Receiver::getUnsettled()
+ {
+ return receiverp->getUnsettled();
+ }
+
+ void Receiver::close()
+ {
+ receiverp->close();
+ }
+
+ System::String ^ Receiver::getName()
+ {
+ return gcnew System::String(receiverp->getName().c_str());
+ }
+
+ Session ^ Receiver::getSession()
+ {
+ return parentSession;
+ }
+}}}}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Receiver.h
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Receiver.h?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Receiver.h (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Receiver.h Mon May 10 20:33:19 2010
@@ -0,0 +1,88 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+#pragma once
+
+#include <windows.h>
+#include <msclr\lock.h>
+#include <oletx2xa.h>
+#include <string>
+#include <limits>
+
+#include "qpid/messaging/Receiver.h"
+#include "qpid/messaging/Session.h"
+#include "qpid/messaging/Message.h"
+#include "qpid/messaging/Duration.h"
+
+namespace qpid {
+namespace messaging {
+ // Dummy class to satisfy linker
+ class ReceiverImpl {};
+}}
+
+namespace org {
+namespace apache {
+namespace qpid {
+namespace messaging {
+
+ /// <summary>
+ /// Mreceiver is a managed wrapper for a ::qpid::messaging::Receiver
+ /// </summary>
+
+ ref class Session;
+ ref class Message;
+ ref class Duration;
+
+ public ref class Receiver
+ {
+ private:
+ // The kept object in the Messaging C++ DLL
+ ::qpid::messaging::Receiver * receiverp;
+
+ // The session that created this Receiver
+ Session ^ parentSession;
+
+ // Kept object lifetime flag
+ bool disposed;
+
+ // Kept object deletion code
+ void Cleanup();
+
+ public:
+ Receiver(::qpid::messaging::Receiver * r,
+ Session ^ sessRef);
+ ~Receiver();
+ !Receiver();
+ Receiver(const Receiver ^ rhs);
+
+ bool get(Message ^ mmsgp);
+ bool get(Message ^ mmsgp, Duration ^ durationp);
+ Message ^ get(Duration ^ durationp);
+
+ bool fetch(Message ^ mmsgp);
+ bool fetch(Message ^ mmsgp, Duration ^ durationp);
+ Message ^ fetch(Duration ^ durationp);
+
+ System::UInt32 getCapacity();
+ System::UInt32 getAvailable();
+ System::UInt32 getUnsettled();
+ void close();
+ System::String ^ getName();
+ Session ^ getSession();
+ };
+}}}}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Sender.cpp
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Sender.cpp?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Sender.cpp (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Sender.cpp Mon May 10 20:33:19 2010
@@ -0,0 +1,121 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+
+#include <windows.h>
+#include <msclr\lock.h>
+#include <oletx2xa.h>
+#include <string>
+#include <limits>
+
+#include "qpid/messaging/Sender.h"
+#include "qpid/messaging/Session.h"
+#include "qpid/messaging/Message.h"
+
+#include "Sender.h"
+#include "Session.h"
+#include "Message.h"
+
+namespace org {
+namespace apache {
+namespace qpid {
+namespace messaging {
+
+ /// <summary>
+ /// Sender a managed wrapper for a ::qpid::messaging::Sender
+ /// </summary>
+
+ Sender::Sender(::qpid::messaging::Sender * s,
+ Session ^ sessRef) :
+ senderp(s),
+ parentSession(sessRef)
+ {
+ }
+
+
+ // Destructor
+ Sender::~Sender()
+ {
+ Cleanup();
+ }
+
+
+ // Finalizer
+ Sender::!Sender()
+ {
+ Cleanup();
+ }
+
+ // Copy constructor
+ Sender::Sender(const Sender % rhs)
+ {
+ senderp = rhs.senderp;
+ parentSession = rhs.parentSession;
+ }
+
+ // Destroys kept object
+ // TODO: add lock
+ void Sender::Cleanup()
+ {
+ if (NULL != senderp)
+ {
+ delete senderp;
+ senderp = NULL;
+ }
+ }
+
+ void Sender::send(Message ^ mmsgp)
+ {
+ senderp->::qpid::messaging::Sender::send(*((*mmsgp).messagep));
+ }
+
+ void Sender::send(Message ^ mmsgp, bool sync)
+ {
+ senderp->::qpid::messaging::Sender::send(*((*mmsgp).messagep), sync);
+ }
+
+ void Sender::setCapacity(System::UInt32 capacity)
+ {
+ senderp->setCapacity(capacity);
+ }
+
+ System::UInt32 Sender::getCapacity()
+ {
+ return senderp->getCapacity();
+ }
+
+ System::UInt32 Sender::getUnsettled()
+ {
+ return senderp->getUnsettled();
+ }
+
+ System::UInt32 Sender::getAvailable()
+ {
+ return senderp->getAvailable();
+ }
+
+ System::String ^ Sender::getName()
+ {
+ return gcnew System::String(senderp->getName().c_str());
+ }
+
+ Session ^ Sender::getSession()
+ {
+ return parentSession;
+ }
+}}}}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Sender.h
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Sender.h?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Sender.h (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Sender.h Mon May 10 20:33:19 2010
@@ -0,0 +1,77 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+#pragma once
+
+#include <windows.h>
+#include <msclr\lock.h>
+#include <oletx2xa.h>
+#include <string>
+#include <limits>
+
+#include "qpid/messaging/Sender.h"
+#include "qpid/messaging/Session.h"
+#include "qpid/messaging/Message.h"
+
+namespace qpid {
+namespace messaging {
+ // Dummy class to satisfy linker
+ class SenderImpl {};
+}}
+
+namespace org {
+namespace apache {
+namespace qpid {
+namespace messaging {
+
+ /// <summary>
+ /// Sender is a managed wrapper for a ::qpid::messaging::Sender
+ /// </summary>
+
+ ref class Session;
+ ref class Message;
+
+ public ref class Sender
+ {
+ private:
+ // The kept object in the Messaging C++ DLL
+ ::qpid::messaging::Sender * senderp;
+
+ // The session that created this Sender
+ Session ^ parentSession;
+
+ // Kept object deletion code
+ void Cleanup();
+
+ public:
+ Sender(::qpid::messaging::Sender * s,
+ Session ^ sessRef);
+ ~Sender();
+ !Sender();
+ Sender(const Sender % rhs);
+
+ void send(Message ^ mmsgp);
+ void send(Message ^ mmsgp, bool sync);
+ void setCapacity(System::UInt32 capacity);
+ System::UInt32 getCapacity();
+ System::UInt32 getUnsettled();
+ System::UInt32 getAvailable();
+ System::String ^ getName();
+ Session ^ getSession();
+ };
+}}}}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Session.cpp
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Session.cpp?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Session.cpp (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Session.cpp Mon May 10 20:33:19 2010
@@ -0,0 +1,186 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+
+#include <windows.h>
+#include <msclr\lock.h>
+#include <oletx2xa.h>
+#include <string>
+#include <limits>
+
+#include "qpid/messaging/Session.h"
+
+#include "QpidMarshal.h"
+#include "Session.h"
+#include "Connection.h"
+#include "Duration.h"
+#include "Receiver.h"
+#include "Sender.h"
+
+namespace org {
+namespace apache {
+namespace qpid {
+namespace messaging {
+
+ /// <summary>
+ /// Session is a managed wrapper for a ::qpid::messaging::Session
+ /// </summary>
+
+ // constructor
+ Session::Session(::qpid::messaging::Session * sp, Connection ^ connRef) :
+ sessionp(sp),
+ parentConnectionp(connRef)
+ {
+ }
+
+
+ // Destructor
+ Session::~Session()
+ {
+ Cleanup();
+ }
+
+
+ // Finalizer
+ Session::!Session()
+ {
+ Cleanup();
+ }
+
+ // copy constructor
+ Session::Session(const Session % rhs)
+ {
+ sessionp = rhs.sessionp;
+ parentConnectionp = rhs.parentConnectionp;
+ }
+
+
+ // Destroys kept object
+ // TODO: add lock
+ void Session::Cleanup()
+ {
+ if (NULL != sessionp)
+ {
+ delete sessionp;
+ sessionp = NULL;
+ }
+ }
+
+ void Session::close()
+ {
+ sessionp->close();
+ }
+
+ void Session::commit()
+ {
+ sessionp->commit();
+ }
+
+ void Session::rollback()
+ {
+ sessionp->rollback();
+ }
+
+ void Session::acknowledge()
+ {
+ sessionp->acknowledge();
+ }
+
+ void Session::acknowledge(bool sync)
+ {
+ sessionp->acknowledge(sync);
+ }
+
+ void Session::sync()
+ {
+ sessionp->sync();
+ }
+
+ void Session::sync(bool block)
+ {
+ sessionp->sync(block);
+ }
+
+ System::UInt32 Session::getReceivable()
+ {
+ return sessionp->getReceivable();
+ }
+
+ System::UInt32 Session::getUnsettledAcks()
+ {
+ return sessionp->getUnsettledAcks();
+ }
+
+ //bool Session::nextReceiver(Receiver)
+ //{
+ // sessionp->nextReceiver(Receiver)
+ //}
+
+ //bool Session::nextReceiver(Receiver, Duration timeout)
+ //{
+ // sessionp->nextReceiver();
+ //}
+
+ //Receiver Session::nextReceiver(Duration timeout)
+ //{
+ //}
+
+
+ Sender ^ Session::createSender (System::String ^ address)
+ {
+ // allocate a native sender
+ ::qpid::messaging::Sender * senderp = new ::qpid::messaging::Sender;
+
+ // create the sender
+ *senderp = sessionp->::qpid::messaging::Session::createSender(QpidMarshal::ToNative(address));
+
+ // create a managed sender
+ Sender ^ newSender = gcnew Sender(senderp, this);
+
+ return newSender;
+ }
+
+ Receiver ^ Session::createReceiver(System::String ^ address)
+ {
+ // allocate a native receiver
+ ::qpid::messaging::Receiver * receiverp = new ::qpid::messaging::Receiver;
+
+ // create the receiver
+ *receiverp = sessionp->createReceiver(QpidMarshal::ToNative(address));
+
+ // create a managed receiver
+ Receiver ^ newReceiver = gcnew Receiver(receiverp, this);
+
+ return newReceiver;
+ }
+
+ Connection ^ Session::getConnection()
+ {
+ return parentConnectionp;
+ }
+
+ bool Session::hasError()
+ {
+ return sessionp->hasError();
+ }
+
+ void Session::checkError()
+ {
+ sessionp->checkError();
+ }
+}}}}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Session.h
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Session.h?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Session.h (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/Session.h Mon May 10 20:33:19 2010
@@ -0,0 +1,93 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+#pragma once
+
+#include <windows.h>
+#include <msclr\lock.h>
+#include <oletx2xa.h>
+#include <string>
+#include <limits>
+
+#include "qpid/messaging/Session.h"
+#include "qpid/messaging/Connection.h"
+#include "qpid/messaging/Duration.h"
+#include "qpid/messaging/Receiver.h"
+#include "qpid/messaging/Sender.h"
+
+namespace qpid {
+namespace messaging {
+ // Dummy class to satisfy linker
+ class SessionImpl {};
+}}
+
+namespace org {
+namespace apache {
+namespace qpid {
+namespace messaging {
+
+ /// <summary>
+ /// Session is a managed wrapper for a ::qpid::messaging::Session
+ /// </summary>
+
+ ref class Connection;
+ ref class Duration;
+ ref class Receiver;
+ ref class Sender;
+
+ public ref class Session
+ {
+ private:
+ // The kept object in the Messaging C++ DLL
+ ::qpid::messaging::Session * sessionp;
+
+ // The connection that created this session
+ Connection ^ parentConnectionp;
+
+ // Kept object deletion code
+ void Cleanup();
+
+ public:
+ Session(::qpid::messaging::Session * sessionp,
+ Connection ^ connRef);
+ ~Session();
+ !Session();
+ Session(const Session % rhs);
+
+ void close();
+ void commit();
+ void rollback();
+ void acknowledge();
+ void acknowledge(bool sync);
+ //void reject(Message);
+ //void release(Message);
+ void sync();
+ void sync(bool block);
+ System::UInt32 getReceivable();
+ System::UInt32 getUnsettledAcks();
+ //bool nextReceiver(Receiver);
+ //bool nextReceiver(Receiver, Duration timeout);
+ //Receiver nextReceiver(Duration timeout);
+ //bool nextReceiver()
+ Sender ^ createSender (System::String ^ address);
+ Receiver ^ createReceiver(System::String ^ address);
+ Connection ^ getConnection();
+ bool hasError();
+ void checkError();
+ };
+}}}}
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/app.rc
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/app.rc?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/app.rc (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/app.rc Mon May 10 20:33:19 2010
@@ -0,0 +1,62 @@
+// Microsoft Visual C++ generated resource script.
+//
+#include "resource.h"
+
+#define APSTUDIO_READONLY_SYMBOLS
+
+/////////////////////////////////////////////////////////////////////////////
+#undef APSTUDIO_READONLY_SYMBOLS
+
+/////////////////////////////////////////////////////////////////////////////
+// English (U.S.) resources
+
+
+/////////////////////////////////////////////////////////////////////////////
+//
+// Icon
+//
+
+// Icon placed first or with lowest ID value becomes application icon
+
+LANGUAGE 9, 1
+#pragma code_page(1252)
+
+#ifdef APSTUDIO_INVOKED
+/////////////////////////////////////////////////////////////////////////////
+//
+// TEXTINCLUDE
+//
+
+1 TEXTINCLUDE
+BEGIN
+ "resource.h\0"
+ "\0"
+END
+
+2 TEXTINCLUDE
+BEGIN
+ "#include ""afxres.h""\r\n"
+ "\0"
+END
+
+3 TEXTINCLUDE
+BEGIN
+ "\0"
+END
+
+#endif // APSTUDIO_INVOKED
+
+/////////////////////////////////////////////////////////////////////////////
+
+
+
+#ifndef APSTUDIO_INVOKED
+/////////////////////////////////////////////////////////////////////////////
+//
+// Generated from the TEXTINCLUDE 3 resource.
+//
+
+
+/////////////////////////////////////////////////////////////////////////////
+#endif // not APSTUDIO_INVOKED
+
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/org.apache.qpid.messaging.vcproj
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/org.apache.qpid.messaging.vcproj?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/org.apache.qpid.messaging.vcproj (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/org.apache.qpid.messaging.vcproj Mon May 10 20:33:19 2010
@@ -0,0 +1,278 @@
+<?xml version="1.0" encoding="Windows-1252"?>
+<VisualStudioProject
+ ProjectType="Visual C++"
+ Version="9.00"
+ Name="org.apache.qpid.messaging"
+ ProjectGUID="{AA5A3B83-5F98-406D-A01C-5A921467A57D}"
+ RootNamespace="org.apache.qpid.messaging"
+ Keyword="ManagedCProj"
+ TargetFrameworkVersion="196613"
+ >
+ <Platforms>
+ <Platform
+ Name="Win32"
+ />
+ </Platforms>
+ <ToolFiles>
+ </ToolFiles>
+ <Configurations>
+ <Configuration
+ Name="Debug|Win32"
+ OutputDirectory="$(SolutionDir)\bin\$(ConfigurationName)"
+ IntermediateDirectory="$(SolutionDir)\obj\$(ConfigurationName)"
+ ConfigurationType="2"
+ CharacterSet="1"
+ ManagedExtensions="1"
+ WholeProgramOptimization="1"
+ >
+ <Tool
+ Name="VCPreBuildEventTool"
+ />
+ <Tool
+ Name="VCCustomBuildTool"
+ />
+ <Tool
+ Name="VCXMLDataGeneratorTool"
+ />
+ <Tool
+ Name="VCWebServiceProxyGeneratorTool"
+ />
+ <Tool
+ Name="VCMIDLTool"
+ />
+ <Tool
+ Name="VCCLCompilerTool"
+ AdditionalOptions=" /Zm1000 /wd4244 /wd4800 /wd4355"
+ Optimization="0"
+ AdditionalIncludeDirectories=""$(QPID_BUILD_ROOT)\include";"$(QPID_BUILD_ROOT)\src""
+ PreprocessorDefinitions="WIN32;_WINDOWS;_DEBUG;WIN32_LEAN_AND_MEAN"
+ RuntimeLibrary="3"
+ UsePrecompiledHeader="0"
+ WarningLevel="3"
+ DebugInformationFormat="3"
+ />
+ <Tool
+ Name="VCManagedResourceCompilerTool"
+ />
+ <Tool
+ Name="VCResourceCompilerTool"
+ />
+ <Tool
+ Name="VCPreLinkEventTool"
+ />
+ <Tool
+ Name="VCLinkerTool"
+ AdditionalOptions=" /STACK:10000000 /machine:I386"
+ AdditionalDependencies="$(QPID_BUILD_ROOT)\src\Debug\qpidclientd.lib $(QPID_BUILD_ROOT)\src\Debug\qpidcommond.lib"
+ OutputFile="$(OutDir)\org.apache.qpid.messagingd.dll"
+ LinkIncremental="1"
+ GenerateDebugInformation="true"
+ AssemblyDebug="1"
+ TargetMachine="1"
+ />
+ <Tool
+ Name="VCALinkTool"
+ />
+ <Tool
+ Name="VCManifestTool"
+ />
+ <Tool
+ Name="VCXDCMakeTool"
+ />
+ <Tool
+ Name="VCBscMakeTool"
+ />
+ <Tool
+ Name="VCFxCopTool"
+ />
+ <Tool
+ Name="VCAppVerifierTool"
+ />
+ <Tool
+ Name="VCPostBuildEventTool"
+ />
+ </Configuration>
+ <Configuration
+ Name="Release|Win32"
+ OutputDirectory="$(SolutionDir)\bin\$(ConfigurationName)"
+ IntermediateDirectory="$(SolutionDir)\obj\$(ConfigurationName)"
+ ConfigurationType="2"
+ CharacterSet="1"
+ ManagedExtensions="1"
+ WholeProgramOptimization="1"
+ >
+ <Tool
+ Name="VCPreBuildEventTool"
+ />
+ <Tool
+ Name="VCCustomBuildTool"
+ />
+ <Tool
+ Name="VCXMLDataGeneratorTool"
+ />
+ <Tool
+ Name="VCWebServiceProxyGeneratorTool"
+ />
+ <Tool
+ Name="VCMIDLTool"
+ />
+ <Tool
+ Name="VCCLCompilerTool"
+ AdditionalOptions=" /Zm1000 /wd4244 /wd4800 /wd4355"
+ Optimization="0"
+ AdditionalIncludeDirectories=""$(QPID_BUILD_ROOT)\include";"$(QPID_BUILD_ROOT)\src""
+ PreprocessorDefinitions="WIN32;_WINDOWS;NDEBUG;WIN32_LEAN_AND_MEAN"
+ RuntimeLibrary="3"
+ UsePrecompiledHeader="0"
+ WarningLevel="3"
+ DebugInformationFormat="3"
+ />
+ <Tool
+ Name="VCManagedResourceCompilerTool"
+ />
+ <Tool
+ Name="VCResourceCompilerTool"
+ />
+ <Tool
+ Name="VCPreLinkEventTool"
+ />
+ <Tool
+ Name="VCLinkerTool"
+ AdditionalOptions=" /STACK:10000000 /machine:I386"
+ AdditionalDependencies="$(QPID_BUILD_ROOT)\src\Release\qpidclient.lib $(QPID_BUILD_ROOT)\src\Release\qpidcommon.lib"
+ OutputFile="$(OutDir)\org.apache.qpid.messaging.dll"
+ LinkIncremental="1"
+ GenerateDebugInformation="true"
+ AssemblyDebug="1"
+ TargetMachine="1"
+ />
+ <Tool
+ Name="VCALinkTool"
+ />
+ <Tool
+ Name="VCManifestTool"
+ />
+ <Tool
+ Name="VCXDCMakeTool"
+ />
+ <Tool
+ Name="VCBscMakeTool"
+ />
+ <Tool
+ Name="VCFxCopTool"
+ />
+ <Tool
+ Name="VCAppVerifierTool"
+ />
+ <Tool
+ Name="VCPostBuildEventTool"
+ />
+ </Configuration>
+ </Configurations>
+ <References>
+ <AssemblyReference
+ RelativePath="System.dll"
+ AssemblyName="System, Version=2.0.0.0, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL"
+ MinFrameworkVersion="131072"
+ />
+ <AssemblyReference
+ RelativePath="System.Data.dll"
+ AssemblyName="System.Data, Version=2.0.0.0, PublicKeyToken=b77a5c561934e089, processorArchitecture=x86"
+ MinFrameworkVersion="131072"
+ />
+ </References>
+ <Files>
+ <Filter
+ Name="Source Files"
+ Filter="cpp;c;cc;cxx;def;odl;idl;hpj;bat;asm;asmx"
+ UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}"
+ >
+ <File
+ RelativePath=".\AssemblyInfo.cpp"
+ >
+ </File>
+ <File
+ RelativePath=".\Connection.cpp"
+ >
+ </File>
+ <File
+ RelativePath=".\Duration.cpp"
+ >
+ </File>
+ <File
+ RelativePath=".\Message.cpp"
+ >
+ </File>
+ <File
+ RelativePath=".\Receiver.cpp"
+ >
+ </File>
+ <File
+ RelativePath=".\Sender.cpp"
+ >
+ </File>
+ <File
+ RelativePath=".\Session.cpp"
+ >
+ </File>
+ </Filter>
+ <Filter
+ Name="Header Files"
+ Filter="h;hpp;hxx;hm;inl;inc;xsd"
+ UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}"
+ >
+ <File
+ RelativePath=".\Connection.h"
+ >
+ </File>
+ <File
+ RelativePath=".\Duration.h"
+ >
+ </File>
+ <File
+ RelativePath=".\Message.h"
+ >
+ </File>
+ <File
+ RelativePath=".\QpidMarshal.h"
+ >
+ </File>
+ <File
+ RelativePath=".\Receiver.h"
+ >
+ </File>
+ <File
+ RelativePath=".\Sender.h"
+ >
+ </File>
+ <File
+ RelativePath=".\Session.h"
+ >
+ </File>
+ </Filter>
+ <Filter
+ Name="Resource Files"
+ Filter="rc;ico;cur;bmp;dlg;rc2;rct;bin;rgs;gif;jpg;jpeg;jpe;resx;tiff;tif;png;wav"
+ UniqueIdentifier="{67DA6AB6-F800-4c08-8B7A-83BB121AAD01}"
+ >
+ <File
+ RelativePath=".\app.ico"
+ >
+ </File>
+ <File
+ RelativePath=".\app.rc"
+ >
+ </File>
+ <File
+ RelativePath=".\resource.h"
+ >
+ </File>
+ </Filter>
+ <File
+ RelativePath=".\ReadMe.txt"
+ >
+ </File>
+ </Files>
+ <Globals>
+ </Globals>
+</VisualStudioProject>
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/resource.h
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/resource.h?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/resource.h (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/src/resource.h Mon May 10 20:33:19 2010
@@ -0,0 +1,22 @@
+/*
+* Licensed to the Apache Software Foundation (ASF) under one
+* or more contributor license agreements. See the NOTICE file
+* distributed with this work for additional information
+* regarding copyright ownership. The ASF licenses this file
+* to you under the Apache License, Version 2.0 (the
+* "License"); you may not use this file except in compliance
+* with the License. You may obtain a copy of the License at
+*
+* http://www.apache.org/licenses/LICENSE-2.0
+*
+* Unless required by applicable law or agreed to in writing,
+* software distributed under the License is distributed on an
+* "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+* KIND, either express or implied. See the License for the
+* specific language governing permissions and limitations
+* under the License.
+*/
+
+//{{NO_DEPENDENCIES}}
+// Microsoft Visual C++ generated include file.
+// Used by app.rc
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/messaging.test/Properties/AssemblyInfo.cs
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/messaging.test/Properties/AssemblyInfo.cs?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/messaging.test/Properties/AssemblyInfo.cs (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/messaging.test/Properties/AssemblyInfo.cs Mon May 10 20:33:19 2010
@@ -0,0 +1,36 @@
+using System.Reflection;
+using System.Runtime.CompilerServices;
+using System.Runtime.InteropServices;
+
+// General Information about an assembly is controlled through the following
+// set of attributes. Change these attribute values to modify the information
+// associated with an assembly.
+[assembly: AssemblyTitle("messaging.test")]
+[assembly: AssemblyDescription("")]
+[assembly: AssemblyConfiguration("")]
+[assembly: AssemblyCompany("")]
+[assembly: AssemblyProduct("messaging.test")]
+[assembly: AssemblyCopyright("Copyright © 2010")]
+[assembly: AssemblyTrademark("")]
+[assembly: AssemblyCulture("")]
+
+// Setting ComVisible to false makes the types in this assembly not visible
+// to COM components. If you need to access a type in this assembly from
+// COM, set the ComVisible attribute to true on that type.
+[assembly: ComVisible(false)]
+
+// The following GUID is for the ID of the typelib if this project is exposed to COM
+[assembly: Guid("fdf30e75-69ba-45c2-a196-df09085dd56a")]
+
+// Version information for an assembly consists of the following four values:
+//
+// Major Version
+// Minor Version
+// Build Number
+// Revision
+//
+// You can specify all the values or you can default the Build and Revision Numbers
+// by using the '*' as shown below:
+// [assembly: AssemblyVersion("1.0.*")]
+[assembly: AssemblyVersion("1.0.0.0")]
+[assembly: AssemblyFileVersion("1.0.0.0")]
Added: qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/messaging.test/messaging.test.cs
URL: http://svn.apache.org/viewvc/qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/messaging.test/messaging.test.cs?rev=942892&view=auto
==============================================================================
--- qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/messaging.test/messaging.test.cs (added)
+++ qpid/trunk/qpid/cpp/bindings/qpid/dotnet/test/messaging.test/messaging.test.cs Mon May 10 20:33:19 2010
@@ -0,0 +1,38 @@
+using System;
+using System.Collections.Generic;
+using System.Linq;
+using System.Text;
+using org.apache.qpid.messaging;
+
+namespace org.apache.qpid.messaging
+{
+ class Program
+ {
+ static void Main(string[] args)
+ {
+ //
+ // Duration test - stub until proper nunit tests are ready...
+ //
+ Duration myDuration = new Duration(1234);
+
+ Console.WriteLine("Duration should be : 1234, is : {0}",
+ myDuration.getMilliseconds());
+
+ Console.WriteLine("Duration FOREVER should be : 1.8x10^19 (realbig), is : {0}",
+ myDuration.FOREVER());
+
+ Console.WriteLine("Duration IMMEDIATE should be : 0, is : {0}",
+ myDuration.IMMEDIATE());
+
+ Console.WriteLine("Duration SECOND should be : 1,000, is : {0}",
+ myDuration.SECOND());
+
+ Console.WriteLine("Duration MINUTE should be : 60,000, is : {0}",
+ myDuration.MINUTE());
+
+ //
+ // and so on
+ //
+ }
+ }
+}
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:commits-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/11/2010 05:22 PM, Martin Ritchie wrote:
>
>
> -- Martin
>
> Sent from my iPhone
>
> On 11 May 2010, at 21:36, Rajith Attapattu <ra...@gmail.com> wrote:
>
>> While I will leave it to the experts to comment about the current
>> approach, may I suggest that we make a prominent notice in our
>> download page that we have deprecated the 0-8 and 0-10 .NET clients.
>> I know that several individuals have put in some very good effort in
>> the thankless task of propping up these two code bases.
>> But we have to be pragmatic, and understand that we do not have the
>> resources to manage all these code bases.
>>
>> I would actually go one step ahead and delete the 0-8 and 0-10 client
>> artefacts from our download page to prevent people from using them any
>> further.
>
> I'd leave the artefacts up for the previosly releases we just should
> ship them again as that implies that have been maintained. I've said
> this before but I think our approach to always releasing every
> component at once is wrong. If no work has been done to maintain or
> test components then they shouldn't get a new release.
+1
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Martin Ritchie <ma...@gmail.com>.
--
Martin
Sent from my iPhone
On 11 May 2010, at 21:36, Rajith Attapattu <ra...@gmail.com> wrote:
> While I will leave it to the experts to comment about the current
> approach, may I suggest that we make a prominent notice in our
> download page that we have deprecated the 0-8 and 0-10 .NET clients.
> I know that several individuals have put in some very good effort in
> the thankless task of propping up these two code bases.
> But we have to be pragmatic, and understand that we do not have the
> resources to manage all these code bases.
>
> I would actually go one step ahead and delete the 0-8 and 0-10 client
> artefacts from our download page to prevent people from using them any
> further.
I'd leave the artefacts up for the previosly releases we just should
ship them again as that implies that have been maintained. I've said
this before but I think our approach to always releasing every
component at once is wrong. If no work has been done to maintain or
test components then they shouldn't get a new release.
> We should also probably move those code bases out of the main tree
> into a "boneyard" dir.
This seem like a good idea we have discussed this notion before. We
also talked about an experimental directory for incomming work, such
as this new client, so we can evaluate and see there is some level of
commitment to maintain it. To that end I've added an experimental dir
to the java broker-plugins, but more on that when I have a full
keyboard.
> Regards,
>
> Rajith
>
> On Tue, May 11, 2010 at 3:36 PM, Gordon Sim <gs...@redhat.com> wrote:
>> On 05/10/2010 09:33 PM, tross@apache.org wrote:
>>>
>>> Author: tross
>>> Date: Mon May 10 20:33:19 2010
>>> New Revision: 942892
>>>
>>> URL: http://svn.apache.org/viewvc?rev=942892&view=rev
>>> Log:
>>> QPID-2589 - Applied patch from Chuck Rolke.
>>
>> This commit adds a new component and yet another approach for .net,
>> specifically a .net wrapper around the c++ messaging API.
>>
>> We also have a wcf client (this also uses some c++ code, but uses
>> the 0-10
>> specific API plus some direct use of the internals of the client),
>> and two
>> different pure c# clients for 0-8 and 0-10 respectively.
>>
>> Four different options each with its own codebase isn't sensible.
>> We can't
>> maintain them all and it is confusing for users.
>>
>> While aspects of this latest approach certainly appeal to me
>> personally (the
>> messaging API is better for a number of reasons than the older API
>> and
>> wrapping that also keeps the clients more aligned conceptually), I
>> think it
>> deserves a bit more debate. Specifically we have to explicitly
>> decide as a
>> community whether this new approach is a path we should pursue. I'm
>> keen to
>> hear the thoughts of Cliff, Aidan and other .net aficionados.
>>
>> --Gordon
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [.net]: some debate please
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: Rajith Attapattu [mailto:rajith77@gmail.com]
>
> While I will leave it to the experts to comment about the
> current approach, may I suggest that we make a prominent
> notice in our download page that we have deprecated the 0-8
> and 0-10 .NET clients.
Good idea... A nice explanation that the .NET 0-8 and 0-10 clients will
not be maintained and will not be in the Qpid 0.8 or future releases,
along with a short explanation why and mention that 0.6 also includes
WCF/.NET which will be included in future versions.
> I know that several individuals have
> put in some very good effort in the thankless task of
> propping up these two code bases. But we have to be
> pragmatic, and understand that we do not have the resources
> to manage all these code bases.
Right, and a plea for improvements/fixes got a little attention months
ago and has since gone dead again, AFAIK.
> I would actually go one step ahead and delete the 0-8 and
> 0-10 client artefacts from our download page to prevent
> people from using them any further. We should also probably
> move those code bases out of the main tree into a "boneyard" dir.
They could always be resurrected from svn if needed - I don't see a need
for a "boneyard" area.
-Steve
> On Tue, May 11, 2010 at 3:36 PM, Gordon Sim <gs...@redhat.com> wrote:
> > On 05/10/2010 09:33 PM, tross@apache.org wrote:
> >>
> >> Author: tross
> >> Date: Mon May 10 20:33:19 2010
> >> New Revision: 942892
> >>
> >> URL: http://svn.apache.org/viewvc?rev=942892&view=rev
> >> Log:
> >> QPID-2589 - Applied patch from Chuck Rolke.
> >
> > This commit adds a new component and yet another approach for .net,
> > specifically a .net wrapper around the c++ messaging API.
> >
> > We also have a wcf client (this also uses some c++ code,
> but uses the
> > 0-10 specific API plus some direct use of the internals of the
> > client), and two different pure c# clients for 0-8 and 0-10
> > respectively.
> >
> > Four different options each with its own codebase isn't
> sensible. We
> > can't maintain them all and it is confusing for users.
> >
> > While aspects of this latest approach certainly appeal to me
> > personally (the messaging API is better for a number of
> reasons than
> > the older API and wrapping that also keeps the clients more aligned
> > conceptually), I think it deserves a bit more debate.
> Specifically we
> > have to explicitly decide as a community whether this new
> approach is
> > a path we should pursue. I'm keen to hear the thoughts of
> Cliff, Aidan
> > and other .net aficionados.
> >
> > --Gordon
> >
> >
> ---------------------------------------------------------------------
> > Apache Qpid - AMQP Messaging Implementation
> > Project: http://qpid.apache.org
> > Use/Interact: mailto:dev-subscribe@qpid.apache.org
> >
> >
>
>
>
> --
> Regards,
>
> Rajith Attapattu
> Red Hat
> http://rajith.2rlabs.com/
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Rajith Attapattu <ra...@gmail.com>.
While I will leave it to the experts to comment about the current
approach, may I suggest that we make a prominent notice in our
download page that we have deprecated the 0-8 and 0-10 .NET clients.
I know that several individuals have put in some very good effort in
the thankless task of propping up these two code bases.
But we have to be pragmatic, and understand that we do not have the
resources to manage all these code bases.
I would actually go one step ahead and delete the 0-8 and 0-10 client
artefacts from our download page to prevent people from using them any
further.
We should also probably move those code bases out of the main tree
into a "boneyard" dir.
Regards,
Rajith
On Tue, May 11, 2010 at 3:36 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 05/10/2010 09:33 PM, tross@apache.org wrote:
>>
>> Author: tross
>> Date: Mon May 10 20:33:19 2010
>> New Revision: 942892
>>
>> URL: http://svn.apache.org/viewvc?rev=942892&view=rev
>> Log:
>> QPID-2589 - Applied patch from Chuck Rolke.
>
> This commit adds a new component and yet another approach for .net,
> specifically a .net wrapper around the c++ messaging API.
>
> We also have a wcf client (this also uses some c++ code, but uses the 0-10
> specific API plus some direct use of the internals of the client), and two
> different pure c# clients for 0-8 and 0-10 respectively.
>
> Four different options each with its own codebase isn't sensible. We can't
> maintain them all and it is confusing for users.
>
> While aspects of this latest approach certainly appeal to me personally (the
> messaging API is better for a number of reasons than the older API and
> wrapping that also keeps the clients more aligned conceptually), I think it
> deserves a bit more debate. Specifically we have to explicitly decide as a
> community whether this new approach is a path we should pursue. I'm keen to
> hear the thoughts of Cliff, Aidan and other .net aficionados.
>
> --Gordon
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, May 17, 2010 at 11:07 AM, Ted Ross <tr...@redhat.com> wrote:
> I commented on the Jira but I'll jump in on this thread in case folks are
> not reading the Jira comments.
>
> The contribution in question is a thin .Net binding for the new C++
> messaging API. This is why it was placed in the qpid/cpp/bindings area and
> not in the qpid/{dotnet,wcf} areas or in its own new top-level-directory.
While it is fine to leave it in qpid/cpp for the time being, I think
long term we could perhaps move to something like the following.
common (or core)
brokers
clients
tools
docs
extras.. etc..
I don't know how feasible that is and how much work is involved.
But I do know that there is some interest among the committers on this
sorta re-org.
So perhaps if there is a will, then there may be way :)
> This is where several other-language bindings currently reside. I think we
> should be developing bindings for the API in as many languages as we can
> (Python, Ruby, PHP, Perl, Java, etc.).
> This binding does not add any "messaging" value to the API. If new features
> or new behavior are desired, the underlying C++ API should be enhanced and
> the language bindings updated to reflect those enhancements.
>
> The contribution simply allows .NET programs in C#, VB, Powershell, Excel,
> etc. to access the Qpid C++ messaging API. It is not in the same category
> as the qpid/wcf code which adds substantial value over and above basic
> messaging.
>
> The advantage of the thin-binding approach over the existing dotnet
> full-client-implementation-in-C# is that it removes the need to support yet
> another full-client implementation. The dotnet code is currently
> unmaintained, we need a better way to support .NET users.
>
> I apologize for committing this patch to trunk without sufficient debate. I
> considered this to be more of an added feature to the C++ client and less of
> a whole-new-direction for .NET. I see that I was wrong and will, of course,
> abide by what the community decides is best.
>
> -Ted
>
>
> On 05/14/2010 04:38 PM, Marnie McCormack wrote:
>>
>> I don't have a strong view on the 'correct' approach since I'm not
>> familiar
>> with the .Net components.
>>
>> However, I agree wholeheartedly with Rafi's comments about dropping this
>> in
>> without a discussion beforehand (and apologies if I missed one?). If I was
>> an existing .Net contributer I'd be pretty hacked off I think !
>>
>> What should we do now while the discussion on this takes place ?
>>
>> Marnie
>>
>>
>>
>>
>> On Wed, May 12, 2010 at 11:59 AM, Rafael
>> Schloming<ra...@redhat.com>wrote:
>>
>>
>>>
>>> Gordon Sim wrote:
>>>
>>>
>>>>
>>>> On 05/10/2010 09:33 PM,tross@apache.org wrote:
>>>>
>>>>
>>>>>
>>>>> Author: tross
>>>>> Date: Mon May 10 20:33:19 2010
>>>>> New Revision: 942892
>>>>>
>>>>> URL:http://svn.apache.org/viewvc?rev=942892&view=rev
>>>>> Log:
>>>>> QPID-2589 - Applied patch from Chuck Rolke.
>>>>>
>>>>>
>>>>
>>>> This commit adds a new component and yet another approach for .net,
>>>> specifically a .net wrapper around the c++ messaging API.
>>>>
>>>> We also have a wcf client (this also uses some c++ code, but uses the
>>>> 0-10
>>>> specific API plus some direct use of the internals of the client), and
>>>> two
>>>> different pure c# clients for 0-8 and 0-10 respectively.
>>>>
>>>> Four different options each with its own codebase isn't sensible. We
>>>> can't
>>>> maintain them all and it is confusing for users.
>>>>
>>>> While aspects of this latest approach certainly appeal to me personally
>>>> (the messaging API is better for a number of reasons than the older API
>>>> and
>>>> wrapping that also keeps the clients more aligned conceptually), I think
>>>> it
>>>> deserves a bit more debate. Specifically we have to explicitly decide as
>>>> a
>>>> community whether this new approach is a path we should pursue. I'm keen
>>>> to
>>>> hear the thoughts of Cliff, Aidan and other .net aficionados.
>>>>
>>>>
>>>
>>> While I prefer depending on the new C++ messaging API to depending on the
>>> old one, I don't think either one is really the correct choice. I think
>>> the
>>> WCF client should actually depend on a C# interface to the message API,
>>> thus
>>> giving something that is more reasonable to use directly from C#, while
>>> being able to be back-ended by either the C++ implementation of the
>>> messaging API or by a pure C# implementation if one is so inclined to
>>> write
>>> one.
>>>
>>> On purely procedural note, it is IMHO *very* bad form to drop such a
>>> patch
>>> into the repo without some list discussion prior. I'm particularly
>>> uncomfortable that this was committed by someone who (as far as I'm
>>> aware)
>>> is not a regular WCF committer, nor intends to become one.
>>>
>>> This has been the general approach in this area since the first dotnet
>>> effort ages ago. It's no wonder there are 4 completely different
>>> approaches
>>> half of which are rotting. Cleaning out the rot is only half the problem
>>> here, we *really* have to stop doing stuff like this or we'll keep on
>>> making
>>> more rot.
>>>
>>> IMHO this patch should be backed out until some discussion has happened
>>> and
>>> its clear that those responsible for maintaining WCF going forward are
>>> comfortable with the approach.
>>>
>>> --Rafael
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project:http://qpid.apache.org
>>> Use/Interact:mailto:dev-subscribe@qpid.apache.org
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Gordon Sim <gs...@redhat.com>.
On 05/17/2010 04:07 PM, Ted Ross wrote:
> The contribution simply allows .NET programs in C#, VB, Powershell,
> Excel, etc. to access the Qpid C++ messaging API. It is not in the same
> category as the qpid/wcf code which adds substantial value over and
> above basic messaging.
>
> The advantage of the thin-binding approach over the existing dotnet
> full-client-implementation-in-C# is that it removes the need to support
> yet another full-client implementation. The dotnet code is currently
> unmaintained, we need a better way to support .NET users.
I agree on both these points[1].
Another aspect of the approach that appeals to me is that it extends the
same concepts that the c++ and python client are built on. This widens
the support base for those questions from .NET users that are not
specific to the .NET interface.
However it also seems sensible to at least consider in this context
whether the WCF functionality could - at some point in the future - be
built on top of this binding[2]. If the WCF stack remains entirely
independent the view that this removes a full-client implementation is
less compelling.
> I apologize for committing this patch to trunk without sufficient
> debate. I considered this to be more of an added feature to the C++
> client and less of a whole-new-direction for .NET.
I understand your point. However, it is another option that we are
potentially offering to .NET users meaning another option we may need to
maintain, document and answer questions for.
Thanks to all those participating in the debate both on this thread and
by Jira; this is exactly what I think we need!
--Gordon
[1] It is probably worth noting though that there are two separate
client implementations in the dotnet directory; one for 0-8 and one for
0-10. The new binding is at present only a valid replacement for the
latter as the c++ client does not support 0-8. Of course now that both
Qpid brokers support 0-10, that is not as big an issue.
[2] That may require some extension of the messaging API of course and
this is being explored on
https://issues.apache.org/jira/browse/QPID-2589 for those interested.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Marnie McCormack <ma...@googlemail.com>.
There are a host of inflight JIRAs for the Broker 0-10 work - but its not a
short list. Its top priority for me.
Marnie
On Tue, May 18, 2010 at 3:46 PM, Carl Trieloff <cc...@redhat.com>wrote:
> On 05/18/2010 10:37 AM, Marnie McCormack wrote:
>
>> I'll confess that I'm fairly uncomfortable with any other new .Net API,
>> especially since the current situation is that we have no client which can
>> interop across both brokers with all the other clients successfully (with
>> the Java Broker 0-10 code not yet complete/prod ready). I'd rather been
>> hoping we could get behind the new WCF client and build that out as the
>> replacement for the existing .Net components.
>>
>>
>
>
> I think the new WCF client is the direction. however it is bound directly
> to the old C++ 0-10 AMQP, and should at some point to updated to
> use the version independent API on the C++ side.
>
> My view is that it mainly about follow-through, and am glad to see Gordon
> and Cliff discussing the issues that need to be addressed to do that.
>
> The way to get the Java broker to talk WCF, without client proliferation
> should
> be to complete the 0-10 work on the Java broker.
>
> Carl.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/18/2010 11:39 AM, Steve Huston wrote:
> Hi Jonathan,
>
>
>> > I want one WCF client that works with both brokers and interops with
>> > clients in all languages. I want only one. I want to avoid
>> > the confusion
>> > of having more than one, and I want to avoid putting effort into more
>> > than one
>> >
>> > I want the WCF client to use the new addressing scheme.
>> >
>> > Am I wanting the right things?
>>
When the Java Broker has 0-10 is complete, you will have this.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [.net]: some debate please
Posted by Steve Huston <sh...@riverace.com>.
Hi Jonathan,
> I want one WCF client that works with both brokers and interops with
> clients in all languages. I want only one. I want to avoid
> the confusion
> of having more than one, and I want to avoid putting effort into more
> than one
>
> I want the WCF client to use the new addressing scheme.
>
> Am I wanting the right things?
Those are good things to want, but that's not what you have now.
As far as interop, clients don't interop with languages; they interop
with AMQP peers. Saying WCF should interop with Python, for example,
isn't the goal - if WCF interops with a broker that your Python client
also interops with, you're good. If both clients can talk to the same
broker but can't exchange messages, that's a problem/bug.
The current WCF client doesn't interop with the pre-0-10 Java broker;
making ti do so would be a serious amount of work. The goal going
forward, I believe, is to focus on 0-10 and 1-0.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Jonathan Robie <jo...@redhat.com>.
I want one WCF client that works with both brokers and interops with
clients in all languages. I want only one. I want to avoid the confusion
of having more than one, and I want to avoid putting effort into more
than one
I want the WCF client to use the new addressing scheme.
Am I wanting the right things?
Jonathan
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/18/2010 10:37 AM, Marnie McCormack wrote:
> I'll confess that I'm fairly uncomfortable with any other new .Net API,
> especially since the current situation is that we have no client which can
> interop across both brokers with all the other clients successfully (with
> the Java Broker 0-10 code not yet complete/prod ready). I'd rather been
> hoping we could get behind the new WCF client and build that out as the
> replacement for the existing .Net components.
>
I think the new WCF client is the direction. however it is bound directly
to the old C++ 0-10 AMQP, and should at some point to updated to
use the version independent API on the C++ side.
My view is that it mainly about follow-through, and am glad to see Gordon
and Cliff discussing the issues that need to be addressed to do that.
The way to get the Java broker to talk WCF, without client proliferation
should
be to complete the 0-10 work on the Java broker.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/18/2010 10:49 AM, Marnie McCormack wrote:
> What client are you talking about here Carl ?
>
>
C++ and Python have been done. Some list discussion has happened on
Java. Ruby needs to be updated to Python style which missed 0.6, I believe
that is not a big job.
I understand that the update of Java client, to have API with ABI under JMS
that can also be used for JCA is a larger task.
WCF client needs to be updated to use new C++ API, discussion
between Cliff and Gordon happening on JIRA.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Marnie McCormack <ma...@googlemail.com>.
What client are you talking about here Carl ?
Marnie
On Tue, May 18, 2010 at 3:48 PM, Carl Trieloff <cc...@redhat.com>wrote:
> On 05/18/2010 10:37 AM, Marnie McCormack wrote:
>
>> Another key point is that if we're going to produce 'bindings' we need to
>> get much better at backwards compatibility on Qpid. We have existing C++
>> clients stranded on an old Qpid build as a result of some of our previous
>> decisions, along with C# users who won't be able to interop.
>>
>
>
> That is is whole point of all the debate on the new APIs, ABI and API
> compat. So we are getting there, big part done for 0.6. It is about
> follow-through and working the remaining client we are going to
> continue to maintain.
>
> Carl.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/18/2010 10:37 AM, Marnie McCormack wrote:
> Another key point is that if we're going to produce 'bindings' we need to
> get much better at backwards compatibility on Qpid. We have existing C++
> clients stranded on an old Qpid build as a result of some of our previous
> decisions, along with C# users who won't be able to interop.
That is is whole point of all the debate on the new APIs, ABI and API
compat. So we are getting there, big part done for 0.6. It is about
follow-through and working the remaining client we are going to
continue to maintain.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Cliff Jansen <cl...@gmail.com>.
> Why would a user chose to use this binding instead
> of the WCF client - I guess thats the key question ?
If I understand the previous posts in this thread, the answer is that
people who are comfortable with WCF paradigms will use WCF, and people
who like to think a little closer to AMQP on the wire will use the new
messaging libraries. (See Rafael's post regarding JMS).
Presumably people who have already written something to the python and
C++ apis may find it more natural to port their work to .NET using
this new binding too.
On Tue, May 18, 2010 at 7:37 AM, Marnie McCormack
<ma...@googlemail.com> wrote:
> I'll confess that I'm fairly uncomfortable with any other new .Net API,
> especially since the current situation is that we have no client which can
> interop across both brokers with all the other clients successfully (with
> the Java Broker 0-10 code not yet complete/prod ready). I'd rather been
> hoping we could get behind the new WCF client and build that out as the
> replacement for the existing .Net components.
> Are there a set of .Net use cases that we're seeking to support - or even a
> set of minimal client use cases that this binding supports ? Does it support
> interop testing in CI ? Why would a user chose to use this binding instead
> of the WCF client - I guess thats the key question ?
>
> Are there docs out there for the bindings ?
>
> Another key point is that if we're going to produce 'bindings' we need to
> get much better at backwards compatibility on Qpid. We have existing C++
> clients stranded on an old Qpid build as a result of some of our previous
> decisions, along with C# users who won't be able to interop. I'd like us to
> start deprecating APIs in a consistent way going forward.
>
> Thanks,
> Marnie
>
>
> On Mon, May 17, 2010 at 4:07 PM, Ted Ross <tr...@redhat.com> wrote:
>
>> I commented on the Jira but I'll jump in on this thread in case folks are
>> not reading the Jira comments.
>>
>> The contribution in question is a thin .Net binding for the new C++
>> messaging API. This is why it was placed in the qpid/cpp/bindings area and
>> not in the qpid/{dotnet,wcf} areas or in its own new top-level-directory.
>> This is where several other-language bindings currently reside. I think we
>> should be developing bindings for the API in as many languages as we can
>> (Python, Ruby, PHP, Perl, Java, etc.).
>>
>> This binding does not add any "messaging" value to the API. If new
>> features or new behavior are desired, the underlying C++ API should be
>> enhanced and the language bindings updated to reflect those enhancements.
>>
>> The contribution simply allows .NET programs in C#, VB, Powershell, Excel,
>> etc. to access the Qpid C++ messaging API. It is not in the same category
>> as the qpid/wcf code which adds substantial value over and above basic
>> messaging.
>>
>> The advantage of the thin-binding approach over the existing dotnet
>> full-client-implementation-in-C# is that it removes the need to support yet
>> another full-client implementation. The dotnet code is currently
>> unmaintained, we need a better way to support .NET users.
>>
>> I apologize for committing this patch to trunk without sufficient debate.
>> I considered this to be more of an added feature to the C++ client and less
>> of a whole-new-direction for .NET. I see that I was wrong and will, of
>> course, abide by what the community decides is best.
>>
>> -Ted
>>
>>
>>
>> On 05/14/2010 04:38 PM, Marnie McCormack wrote:
>>
>>> I don't have a strong view on the 'correct' approach since I'm not
>>> familiar
>>> with the .Net components.
>>>
>>> However, I agree wholeheartedly with Rafi's comments about dropping this
>>> in
>>> without a discussion beforehand (and apologies if I missed one?). If I was
>>> an existing .Net contributer I'd be pretty hacked off I think !
>>>
>>> What should we do now while the discussion on this takes place ?
>>>
>>> Marnie
>>>
>>>
>>>
>>>
>>> On Wed, May 12, 2010 at 11:59 AM, Rafael Schloming<rafaels@redhat.com
>>> >wrote:
>>>
>>>
>>>
>>>> Gordon Sim wrote:
>>>>
>>>>
>>>>
>>>>> On 05/10/2010 09:33 PM,tross@apache.org wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Author: tross
>>>>>> Date: Mon May 10 20:33:19 2010
>>>>>> New Revision: 942892
>>>>>>
>>>>>> URL:http://svn.apache.org/viewvc?rev=942892&view=rev
>>>>>> Log:
>>>>>> QPID-2589 - Applied patch from Chuck Rolke.
>>>>>>
>>>>>>
>>>>>>
>>>>> This commit adds a new component and yet another approach for .net,
>>>>> specifically a .net wrapper around the c++ messaging API.
>>>>>
>>>>> We also have a wcf client (this also uses some c++ code, but uses the
>>>>> 0-10
>>>>> specific API plus some direct use of the internals of the client), and
>>>>> two
>>>>> different pure c# clients for 0-8 and 0-10 respectively.
>>>>>
>>>>> Four different options each with its own codebase isn't sensible. We
>>>>> can't
>>>>> maintain them all and it is confusing for users.
>>>>>
>>>>> While aspects of this latest approach certainly appeal to me personally
>>>>> (the messaging API is better for a number of reasons than the older API
>>>>> and
>>>>> wrapping that also keeps the clients more aligned conceptually), I think
>>>>> it
>>>>> deserves a bit more debate. Specifically we have to explicitly decide as
>>>>> a
>>>>> community whether this new approach is a path we should pursue. I'm keen
>>>>> to
>>>>> hear the thoughts of Cliff, Aidan and other .net aficionados.
>>>>>
>>>>>
>>>>>
>>>> While I prefer depending on the new C++ messaging API to depending on the
>>>> old one, I don't think either one is really the correct choice. I think
>>>> the
>>>> WCF client should actually depend on a C# interface to the message API,
>>>> thus
>>>> giving something that is more reasonable to use directly from C#, while
>>>> being able to be back-ended by either the C++ implementation of the
>>>> messaging API or by a pure C# implementation if one is so inclined to
>>>> write
>>>> one.
>>>>
>>>> On purely procedural note, it is IMHO *very* bad form to drop such a
>>>> patch
>>>> into the repo without some list discussion prior. I'm particularly
>>>> uncomfortable that this was committed by someone who (as far as I'm
>>>> aware)
>>>> is not a regular WCF committer, nor intends to become one.
>>>>
>>>> This has been the general approach in this area since the first dotnet
>>>> effort ages ago. It's no wonder there are 4 completely different
>>>> approaches
>>>> half of which are rotting. Cleaning out the rot is only half the problem
>>>> here, we *really* have to stop doing stuff like this or we'll keep on
>>>> making
>>>> more rot.
>>>>
>>>> IMHO this patch should be backed out until some discussion has happened
>>>> and
>>>> its clear that those responsible for maintaining WCF going forward are
>>>> comfortable with the approach.
>>>>
>>>> --Rafael
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> Apache Qpid - AMQP Messaging Implementation
>>>> Project:http://qpid.apache.org
>>>> Use/Interact:mailto:dev-subscribe@qpid.apache.org
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project: http://qpid.apache.org
>> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>>
>>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Marnie McCormack <ma...@googlemail.com>.
I'll confess that I'm fairly uncomfortable with any other new .Net API,
especially since the current situation is that we have no client which can
interop across both brokers with all the other clients successfully (with
the Java Broker 0-10 code not yet complete/prod ready). I'd rather been
hoping we could get behind the new WCF client and build that out as the
replacement for the existing .Net components.
Are there a set of .Net use cases that we're seeking to support - or even a
set of minimal client use cases that this binding supports ? Does it support
interop testing in CI ? Why would a user chose to use this binding instead
of the WCF client - I guess thats the key question ?
Are there docs out there for the bindings ?
Another key point is that if we're going to produce 'bindings' we need to
get much better at backwards compatibility on Qpid. We have existing C++
clients stranded on an old Qpid build as a result of some of our previous
decisions, along with C# users who won't be able to interop. I'd like us to
start deprecating APIs in a consistent way going forward.
Thanks,
Marnie
On Mon, May 17, 2010 at 4:07 PM, Ted Ross <tr...@redhat.com> wrote:
> I commented on the Jira but I'll jump in on this thread in case folks are
> not reading the Jira comments.
>
> The contribution in question is a thin .Net binding for the new C++
> messaging API. This is why it was placed in the qpid/cpp/bindings area and
> not in the qpid/{dotnet,wcf} areas or in its own new top-level-directory.
> This is where several other-language bindings currently reside. I think we
> should be developing bindings for the API in as many languages as we can
> (Python, Ruby, PHP, Perl, Java, etc.).
>
> This binding does not add any "messaging" value to the API. If new
> features or new behavior are desired, the underlying C++ API should be
> enhanced and the language bindings updated to reflect those enhancements.
>
> The contribution simply allows .NET programs in C#, VB, Powershell, Excel,
> etc. to access the Qpid C++ messaging API. It is not in the same category
> as the qpid/wcf code which adds substantial value over and above basic
> messaging.
>
> The advantage of the thin-binding approach over the existing dotnet
> full-client-implementation-in-C# is that it removes the need to support yet
> another full-client implementation. The dotnet code is currently
> unmaintained, we need a better way to support .NET users.
>
> I apologize for committing this patch to trunk without sufficient debate.
> I considered this to be more of an added feature to the C++ client and less
> of a whole-new-direction for .NET. I see that I was wrong and will, of
> course, abide by what the community decides is best.
>
> -Ted
>
>
>
> On 05/14/2010 04:38 PM, Marnie McCormack wrote:
>
>> I don't have a strong view on the 'correct' approach since I'm not
>> familiar
>> with the .Net components.
>>
>> However, I agree wholeheartedly with Rafi's comments about dropping this
>> in
>> without a discussion beforehand (and apologies if I missed one?). If I was
>> an existing .Net contributer I'd be pretty hacked off I think !
>>
>> What should we do now while the discussion on this takes place ?
>>
>> Marnie
>>
>>
>>
>>
>> On Wed, May 12, 2010 at 11:59 AM, Rafael Schloming<rafaels@redhat.com
>> >wrote:
>>
>>
>>
>>> Gordon Sim wrote:
>>>
>>>
>>>
>>>> On 05/10/2010 09:33 PM,tross@apache.org wrote:
>>>>
>>>>
>>>>
>>>>> Author: tross
>>>>> Date: Mon May 10 20:33:19 2010
>>>>> New Revision: 942892
>>>>>
>>>>> URL:http://svn.apache.org/viewvc?rev=942892&view=rev
>>>>> Log:
>>>>> QPID-2589 - Applied patch from Chuck Rolke.
>>>>>
>>>>>
>>>>>
>>>> This commit adds a new component and yet another approach for .net,
>>>> specifically a .net wrapper around the c++ messaging API.
>>>>
>>>> We also have a wcf client (this also uses some c++ code, but uses the
>>>> 0-10
>>>> specific API plus some direct use of the internals of the client), and
>>>> two
>>>> different pure c# clients for 0-8 and 0-10 respectively.
>>>>
>>>> Four different options each with its own codebase isn't sensible. We
>>>> can't
>>>> maintain them all and it is confusing for users.
>>>>
>>>> While aspects of this latest approach certainly appeal to me personally
>>>> (the messaging API is better for a number of reasons than the older API
>>>> and
>>>> wrapping that also keeps the clients more aligned conceptually), I think
>>>> it
>>>> deserves a bit more debate. Specifically we have to explicitly decide as
>>>> a
>>>> community whether this new approach is a path we should pursue. I'm keen
>>>> to
>>>> hear the thoughts of Cliff, Aidan and other .net aficionados.
>>>>
>>>>
>>>>
>>> While I prefer depending on the new C++ messaging API to depending on the
>>> old one, I don't think either one is really the correct choice. I think
>>> the
>>> WCF client should actually depend on a C# interface to the message API,
>>> thus
>>> giving something that is more reasonable to use directly from C#, while
>>> being able to be back-ended by either the C++ implementation of the
>>> messaging API or by a pure C# implementation if one is so inclined to
>>> write
>>> one.
>>>
>>> On purely procedural note, it is IMHO *very* bad form to drop such a
>>> patch
>>> into the repo without some list discussion prior. I'm particularly
>>> uncomfortable that this was committed by someone who (as far as I'm
>>> aware)
>>> is not a regular WCF committer, nor intends to become one.
>>>
>>> This has been the general approach in this area since the first dotnet
>>> effort ages ago. It's no wonder there are 4 completely different
>>> approaches
>>> half of which are rotting. Cleaning out the rot is only half the problem
>>> here, we *really* have to stop doing stuff like this or we'll keep on
>>> making
>>> more rot.
>>>
>>> IMHO this patch should be backed out until some discussion has happened
>>> and
>>> its clear that those responsible for maintaining WCF going forward are
>>> comfortable with the approach.
>>>
>>> --Rafael
>>>
>>>
>>> ---------------------------------------------------------------------
>>> Apache Qpid - AMQP Messaging Implementation
>>> Project:http://qpid.apache.org
>>> Use/Interact:mailto:dev-subscribe@qpid.apache.org
>>>
>>>
>>>
>>>
>>
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [.net]: some debate please
Posted by Ted Ross <tr...@redhat.com>.
I commented on the Jira but I'll jump in on this thread in case folks
are not reading the Jira comments.
The contribution in question is a thin .Net binding for the new C++
messaging API. This is why it was placed in the qpid/cpp/bindings area
and not in the qpid/{dotnet,wcf} areas or in its own new
top-level-directory. This is where several other-language bindings
currently reside. I think we should be developing bindings for the API
in as many languages as we can (Python, Ruby, PHP, Perl, Java, etc.).
This binding does not add any "messaging" value to the API. If new
features or new behavior are desired, the underlying C++ API should be
enhanced and the language bindings updated to reflect those enhancements.
The contribution simply allows .NET programs in C#, VB, Powershell,
Excel, etc. to access the Qpid C++ messaging API. It is not in the same
category as the qpid/wcf code which adds substantial value over and
above basic messaging.
The advantage of the thin-binding approach over the existing dotnet
full-client-implementation-in-C# is that it removes the need to support
yet another full-client implementation. The dotnet code is currently
unmaintained, we need a better way to support .NET users.
I apologize for committing this patch to trunk without sufficient
debate. I considered this to be more of an added feature to the C++
client and less of a whole-new-direction for .NET. I see that I was
wrong and will, of course, abide by what the community decides is best.
-Ted
On 05/14/2010 04:38 PM, Marnie McCormack wrote:
> I don't have a strong view on the 'correct' approach since I'm not familiar
> with the .Net components.
>
> However, I agree wholeheartedly with Rafi's comments about dropping this in
> without a discussion beforehand (and apologies if I missed one?). If I was
> an existing .Net contributer I'd be pretty hacked off I think !
>
> What should we do now while the discussion on this takes place ?
>
> Marnie
>
>
>
>
> On Wed, May 12, 2010 at 11:59 AM, Rafael Schloming<ra...@redhat.com>wrote:
>
>
>> Gordon Sim wrote:
>>
>>
>>> On 05/10/2010 09:33 PM,tross@apache.org wrote:
>>>
>>>
>>>> Author: tross
>>>> Date: Mon May 10 20:33:19 2010
>>>> New Revision: 942892
>>>>
>>>> URL:http://svn.apache.org/viewvc?rev=942892&view=rev
>>>> Log:
>>>> QPID-2589 - Applied patch from Chuck Rolke.
>>>>
>>>>
>>> This commit adds a new component and yet another approach for .net,
>>> specifically a .net wrapper around the c++ messaging API.
>>>
>>> We also have a wcf client (this also uses some c++ code, but uses the 0-10
>>> specific API plus some direct use of the internals of the client), and two
>>> different pure c# clients for 0-8 and 0-10 respectively.
>>>
>>> Four different options each with its own codebase isn't sensible. We can't
>>> maintain them all and it is confusing for users.
>>>
>>> While aspects of this latest approach certainly appeal to me personally
>>> (the messaging API is better for a number of reasons than the older API and
>>> wrapping that also keeps the clients more aligned conceptually), I think it
>>> deserves a bit more debate. Specifically we have to explicitly decide as a
>>> community whether this new approach is a path we should pursue. I'm keen to
>>> hear the thoughts of Cliff, Aidan and other .net aficionados.
>>>
>>>
>> While I prefer depending on the new C++ messaging API to depending on the
>> old one, I don't think either one is really the correct choice. I think the
>> WCF client should actually depend on a C# interface to the message API, thus
>> giving something that is more reasonable to use directly from C#, while
>> being able to be back-ended by either the C++ implementation of the
>> messaging API or by a pure C# implementation if one is so inclined to write
>> one.
>>
>> On purely procedural note, it is IMHO *very* bad form to drop such a patch
>> into the repo without some list discussion prior. I'm particularly
>> uncomfortable that this was committed by someone who (as far as I'm aware)
>> is not a regular WCF committer, nor intends to become one.
>>
>> This has been the general approach in this area since the first dotnet
>> effort ages ago. It's no wonder there are 4 completely different approaches
>> half of which are rotting. Cleaning out the rot is only half the problem
>> here, we *really* have to stop doing stuff like this or we'll keep on making
>> more rot.
>>
>> IMHO this patch should be backed out until some discussion has happened and
>> its clear that those responsible for maintaining WCF going forward are
>> comfortable with the approach.
>>
>> --Rafael
>>
>>
>> ---------------------------------------------------------------------
>> Apache Qpid - AMQP Messaging Implementation
>> Project:http://qpid.apache.org
>> Use/Interact:mailto:dev-subscribe@qpid.apache.org
>>
>>
>>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Marnie McCormack <ma...@googlemail.com>.
I don't have a strong view on the 'correct' approach since I'm not familiar
with the .Net components.
However, I agree wholeheartedly with Rafi's comments about dropping this in
without a discussion beforehand (and apologies if I missed one?). If I was
an existing .Net contributer I'd be pretty hacked off I think !
What should we do now while the discussion on this takes place ?
Marnie
On Wed, May 12, 2010 at 11:59 AM, Rafael Schloming <ra...@redhat.com>wrote:
> Gordon Sim wrote:
>
>> On 05/10/2010 09:33 PM, tross@apache.org wrote:
>>
>>> Author: tross
>>> Date: Mon May 10 20:33:19 2010
>>> New Revision: 942892
>>>
>>> URL: http://svn.apache.org/viewvc?rev=942892&view=rev
>>> Log:
>>> QPID-2589 - Applied patch from Chuck Rolke.
>>>
>>
>> This commit adds a new component and yet another approach for .net,
>> specifically a .net wrapper around the c++ messaging API.
>>
>> We also have a wcf client (this also uses some c++ code, but uses the 0-10
>> specific API plus some direct use of the internals of the client), and two
>> different pure c# clients for 0-8 and 0-10 respectively.
>>
>> Four different options each with its own codebase isn't sensible. We can't
>> maintain them all and it is confusing for users.
>>
>> While aspects of this latest approach certainly appeal to me personally
>> (the messaging API is better for a number of reasons than the older API and
>> wrapping that also keeps the clients more aligned conceptually), I think it
>> deserves a bit more debate. Specifically we have to explicitly decide as a
>> community whether this new approach is a path we should pursue. I'm keen to
>> hear the thoughts of Cliff, Aidan and other .net aficionados.
>>
>
> While I prefer depending on the new C++ messaging API to depending on the
> old one, I don't think either one is really the correct choice. I think the
> WCF client should actually depend on a C# interface to the message API, thus
> giving something that is more reasonable to use directly from C#, while
> being able to be back-ended by either the C++ implementation of the
> messaging API or by a pure C# implementation if one is so inclined to write
> one.
>
> On purely procedural note, it is IMHO *very* bad form to drop such a patch
> into the repo without some list discussion prior. I'm particularly
> uncomfortable that this was committed by someone who (as far as I'm aware)
> is not a regular WCF committer, nor intends to become one.
>
> This has been the general approach in this area since the first dotnet
> effort ages ago. It's no wonder there are 4 completely different approaches
> half of which are rotting. Cleaning out the rot is only half the problem
> here, we *really* have to stop doing stuff like this or we'll keep on making
> more rot.
>
> IMHO this patch should be backed out until some discussion has happened and
> its clear that those responsible for maintaining WCF going forward are
> comfortable with the approach.
>
> --Rafael
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
Re: [.net]: some debate please
Posted by Rafael Schloming <ra...@redhat.com>.
Gordon Sim wrote:
> On 05/10/2010 09:33 PM, tross@apache.org wrote:
>> Author: tross
>> Date: Mon May 10 20:33:19 2010
>> New Revision: 942892
>>
>> URL: http://svn.apache.org/viewvc?rev=942892&view=rev
>> Log:
>> QPID-2589 - Applied patch from Chuck Rolke.
>
> This commit adds a new component and yet another approach for .net,
> specifically a .net wrapper around the c++ messaging API.
>
> We also have a wcf client (this also uses some c++ code, but uses the
> 0-10 specific API plus some direct use of the internals of the client),
> and two different pure c# clients for 0-8 and 0-10 respectively.
>
> Four different options each with its own codebase isn't sensible. We
> can't maintain them all and it is confusing for users.
>
> While aspects of this latest approach certainly appeal to me personally
> (the messaging API is better for a number of reasons than the older API
> and wrapping that also keeps the clients more aligned conceptually), I
> think it deserves a bit more debate. Specifically we have to explicitly
> decide as a community whether this new approach is a path we should
> pursue. I'm keen to hear the thoughts of Cliff, Aidan and other .net
> aficionados.
While I prefer depending on the new C++ messaging API to depending on
the old one, I don't think either one is really the correct choice. I
think the WCF client should actually depend on a C# interface to the
message API, thus giving something that is more reasonable to use
directly from C#, while being able to be back-ended by either the C++
implementation of the messaging API or by a pure C# implementation if
one is so inclined to write one.
On purely procedural note, it is IMHO *very* bad form to drop such a
patch into the repo without some list discussion prior. I'm particularly
uncomfortable that this was committed by someone who (as far as I'm
aware) is not a regular WCF committer, nor intends to become one.
This has been the general approach in this area since the first dotnet
effort ages ago. It's no wonder there are 4 completely different
approaches half of which are rotting. Cleaning out the rot is only half
the problem here, we *really* have to stop doing stuff like this or
we'll keep on making more rot.
IMHO this patch should be backed out until some discussion has happened
and its clear that those responsible for maintaining WCF going forward
are comfortable with the approach.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Rafael Schloming <ra...@redhat.com>.
Cliff Jansen wrote:
> Perhaps it would be useful for somebody to assist this debate by
> introducing the messaging API in the .NET context and addressing why,
> for example, .NET programmers need this API, but Java programmers
> don't. Or why a developer who might be inclined to use WCF should use
> this messaging API instead.
I think Java developers do need this as it addresses a number of use
cases that are not possible with JMS, e.g. explicit control over sync vs
async publish, unacked message windows, and prefetch, as well as better
support for non-blocking programming models. It's just lower priority
because JMS covers many of the common cases already. Also, it makes
sense to build it out and let it mature a bit in C++/Python before
trying to take it to other languages.
Really this API isn't a million miles away from JMS anyways, so an ideal
architecture would be JMS as a very thin layer on top of a Java version
of the API. This would allow people to use JMS for many things they
already know how to do there and then drop into the API for more
advanced scenarios.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Gordon Sim <gs...@redhat.com>.
On 05/12/2010 12:50 PM, Rafael Schloming wrote:
> Even if there isn't interest in using this API directly, I think there
> is huge benefit to having all the clients share a common architecture as
> much as possible. Since the purpose of the messaging API is really to
> expose all the features of AMQP while abstracting away the protocol
> details and not imposing a particular programming model on the
> application (e.g. not requiring applications to dedicate threads to
> handle blocking calls), it makes sense to me that each client would have
> a layer that corresponds to this even if it is not necessarily exposed
> directly.
I agree 100%!
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Rafael Schloming <ra...@redhat.com>.
Gordon Sim wrote:
> On 05/12/2010 11:21 AM, Cliff Jansen wrote:
>> Perhaps it would be useful for somebody to assist this debate by
>> introducing the messaging API in the .NET context and addressing why,
>> for example, .NET programmers need this API, but Java programmers
>> don't. Or why a developer who might be inclined to use WCF should use
>> this messaging API instead.
>>
>> Looking at the initial code drop, I have a very hard time imagining a
>> .NET programmer who might feel remotely comfortable using it. This is
>> not a comment on the quality or functionality of the module, just on
>> the utter disregard for basic .NET conventions of the C++ API as
>> transposed to .NET, i.e. the surface area of the library. I don't
>> think it would take a lot of work to address this.
>
> I think a natural .NET interface is essential ans I expect on that point
> we will all agree.
>
> Whether there would be any interest in using an API like that available
> in c++/python directly instead of just using WCF is an important
> question. I don't have an answer for that at present.
Even if there isn't interest in using this API directly, I think there
is huge benefit to having all the clients share a common architecture as
much as possible. Since the purpose of the messaging API is really to
expose all the features of AMQP while abstracting away the protocol
details and not imposing a particular programming model on the
application (e.g. not requiring applications to dedicate threads to
handle blocking calls), it makes sense to me that each client would have
a layer that corresponds to this even if it is not necessarily exposed
directly.
Obviously this particularly makes sense for languages that can directly
use C/C++ code via swig or other means (which is actually pretty much
any language).
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Gordon Sim <gs...@redhat.com>.
On 05/12/2010 11:21 AM, Cliff Jansen wrote:
> Perhaps it would be useful for somebody to assist this debate by
> introducing the messaging API in the .NET context and addressing why,
> for example, .NET programmers need this API, but Java programmers
> don't. Or why a developer who might be inclined to use WCF should use
> this messaging API instead.
>
> Looking at the initial code drop, I have a very hard time imagining a
> .NET programmer who might feel remotely comfortable using it. This is
> not a comment on the quality or functionality of the module, just on
> the utter disregard for basic .NET conventions of the C++ API as
> transposed to .NET, i.e. the surface area of the library. I don't
> think it would take a lot of work to address this.
I think a natural .NET interface is essential ans I expect on that point
we will all agree.
Whether there would be any interest in using an API like that available
in c++/python directly instead of just using WCF is an important
question. I don't have an answer for that at present.
> The question
> remains whether this new client intends to ignore distributed
> transactions, including the new promotable transactions in AMQP 1.0.
We certainly do want the c++ messaging API to be extended to allow
distributed transaction support to be added. (I'd also be keen on
exploring any optimisations on handling body content).
> But compared to the existing dotnet client, from a practical point of
> view, a module whose heavy lifting is largely done in the C++ space
> will automatically benefit from bug fixes to that code base. This
> beats the current dotnet mechanism of running a code translator
> against a Java snapshot every other year.
I think the approach to implementing whatever interface(s) is(are)
exposed to .NET users is also important to us as a community. Re-using
another implementation to reduce the amount of specific code clearly has
the potential to reduce the maintenance burden. It may of course have
some downsides as well.
The key I think is to discuss these points openly and try to reach some
agreement on approach. We need to co-ordinate our efforts and we can
only do so by sharing our ideas.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Cliff Jansen <cl...@gmail.com>.
Perhaps it would be useful for somebody to assist this debate by
introducing the messaging API in the .NET context and addressing why,
for example, .NET programmers need this API, but Java programmers
don't. Or why a developer who might be inclined to use WCF should use
this messaging API instead.
Looking at the initial code drop, I have a very hard time imagining a
.NET programmer who might feel remotely comfortable using it. This is
not a comment on the quality or functionality of the module, just on
the utter disregard for basic .NET conventions of the C++ API as
transposed to .NET, i.e. the surface area of the library. I don't
think it would take a lot of work to address this. The question
remains whether this new client intends to ignore distributed
transactions, including the new promotable transactions in AMQP 1.0.
But compared to the existing dotnet client, from a practical point of
view, a module whose heavy lifting is largely done in the C++ space
will automatically benefit from bug fixes to that code base. This
beats the current dotnet mechanism of running a code translator
against a Java snapshot every other year.
Carl Trieloff wrote:
> The current WCF uses the 0-10 API, I would suggest moving the WCF client
> to the updated C++ API. I believe this has been agreed to be done at some
> point before on the list which would then be consistent with this work
Actually the current WCF implementation uses the 0-10 C++ API where
convenient and bypasses it when necessary. The complete lack of
distributed transaction support in the updated C++ API means that even
more "behind the scenes" work will be required. But wherever
possible, the new messaging API would be used.
Regardless of recent events, the "Interop" layer of the WCF channel
was known to need rewriting for AMQP 1.0. I had hoped that the
rewrite would lead to a 0-10 and 1.0 friendly library which, surprise,
looks much like this messaging API plus qpid-config. But,
realistically, that would happen after many of the other TODO items in
the WCF Reame file were done.
Cliff
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/11/2010 05:59 PM, Steve Huston wrote:
>> > The current WCF uses the 0-10 API, I would suggest moving the
>> > WCF client to the updated C++ API. I believe this has been
>> > agreed to be done at some point before on the list which
>> > would then be consistent with this work
>>
> Ok, as long as somebody is committed to follow through with it - the
> existing WCF was a sizeable effort.
>
>
Ack, I don't think there is a rush, but it would be needed to be done at
least by the time AMQP 1.0 support is added.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [.net]: some debate please
Posted by Steve Huston <sh...@riverace.com>.
Hi Carl,
> -----Original Message-----
> From: Carl Trieloff [mailto:cctrieloff@redhat.com]
>
> On 05/11/2010 04:28 PM, Steve Huston wrote:
> >> -----Original Message-----
> >> From: Gordon Sim [mailto:gsim@redhat.com]
> >>
> >> On 05/10/2010 09:33 PM, tross@apache.org wrote:
> >>
> >>> Author: tross
> >>> Date: Mon May 10 20:33:19 2010
> >>> New Revision: 942892
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=942892&view=rev
> >>> Log:
> >>> QPID-2589 - Applied patch from Chuck Rolke.
> >>>
> >> This commit adds a new component and yet another approach
> for .net,
> >> specifically a .net wrapper around the c++ messaging API.
> >>
> >> We also have a wcf client (this also uses some c++ code,
> but uses the
> >> 0-10 specific API plus some direct use of the internals of the
> >> client), and two different pure c# clients for 0-8 and 0-10
> >> respectively.
> >>
> >> Four different options each with its own codebase isn't
> sensible. We
> >> can't maintain them all and it is confusing for users.
> >>
> > Right. This is nuts.
> >
> >
> >> While aspects of this latest approach certainly appeal to me
> >> personally (the messaging API is better for a number of
> reasons than
> >> the older API
> >> and wrapping that also keeps the clients more aligned
> >> conceptually), I
> >> think it deserves a bit more debate. Specifically we have to
> >> explicitly
> >> decide as a community whether this new approach is a path we should
> >> pursue. I'm keen to hear the thoughts of Cliff, Aidan and
> other .net
> >> aficionados.
> >>
> > I'm certainly not up to Cliff's level w/ .NET but I agree
> with Gordon
> > - this new approach is more elegant and probably more maintainable.
> > However, nobody has discussed:
> >
> > - What about the older .NET component(s)?
> >
>
> Deprecate them
I agree with this.
> > - How might this affect WCF?
> >
>
> The current WCF uses the 0-10 API, I would suggest moving the
> WCF client to the updated C++ API. I believe this has been
> agreed to be done at some point before on the list which
> would then be consistent with this work
Ok, as long as somebody is committed to follow through with it - the
existing WCF was a sizeable effort.
> > - Has anyone thought of how to package this?
> >
>
> I would package in the same way we package QMF binding to C++
Ok... Again, someone needs to follow through with this. I don't have
funding at this point to extend the installer for 0.8.
> > - Does it have any documentation or tests?
> >
>
> no idea..
Code without tests is a bad idea. I'd also say that new client/user code
must have documentation too.
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: [.net]: some debate please
Posted by Carl Trieloff <cc...@redhat.com>.
On 05/11/2010 04:28 PM, Steve Huston wrote:
>> -----Original Message-----
>> From: Gordon Sim [mailto:gsim@redhat.com]
>>
>> On 05/10/2010 09:33 PM, tross@apache.org wrote:
>>
>>> Author: tross
>>> Date: Mon May 10 20:33:19 2010
>>> New Revision: 942892
>>>
>>> URL: http://svn.apache.org/viewvc?rev=942892&view=rev
>>> Log:
>>> QPID-2589 - Applied patch from Chuck Rolke.
>>>
>> This commit adds a new component and yet another approach for .net,
>> specifically a .net wrapper around the c++ messaging API.
>>
>> We also have a wcf client (this also uses some c++ code, but uses the
>> 0-10 specific API plus some direct use of the internals of
>> the client),
>> and two different pure c# clients for 0-8 and 0-10 respectively.
>>
>> Four different options each with its own codebase isn't sensible. We
>> can't maintain them all and it is confusing for users.
>>
> Right. This is nuts.
>
>
>> While aspects of this latest approach certainly appeal to me
>> personally
>> (the messaging API is better for a number of reasons than the
>> older API
>> and wrapping that also keeps the clients more aligned
>> conceptually), I
>> think it deserves a bit more debate. Specifically we have to
>> explicitly
>> decide as a community whether this new approach is a path we should
>> pursue. I'm keen to hear the thoughts of Cliff, Aidan and other .net
>> aficionados.
>>
> I'm certainly not up to Cliff's level w/ .NET but I agree with Gordon -
> this new approach is more elegant and probably more maintainable.
> However, nobody has discussed:
>
> - What about the older .NET component(s)?
>
Deprecate them
> - How might this affect WCF?
>
The current WCF uses the 0-10 API, I would suggest moving the WCF client
to the updated C++ API. I believe this has been agreed to be done at some
point before on the list which would then be consistent with this work
> - Has anyone thought of how to package this?
>
I would package in the same way we package QMF binding to C++
> - Does it have any documentation or tests?
>
no idea..
my 2 cents.
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: [.net]: some debate please
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: Gordon Sim [mailto:gsim@redhat.com]
>
> On 05/10/2010 09:33 PM, tross@apache.org wrote:
> > Author: tross
> > Date: Mon May 10 20:33:19 2010
> > New Revision: 942892
> >
> > URL: http://svn.apache.org/viewvc?rev=942892&view=rev
> > Log:
> > QPID-2589 - Applied patch from Chuck Rolke.
>
> This commit adds a new component and yet another approach for .net,
> specifically a .net wrapper around the c++ messaging API.
>
> We also have a wcf client (this also uses some c++ code, but uses the
> 0-10 specific API plus some direct use of the internals of
> the client),
> and two different pure c# clients for 0-8 and 0-10 respectively.
>
> Four different options each with its own codebase isn't sensible. We
> can't maintain them all and it is confusing for users.
Right. This is nuts.
> While aspects of this latest approach certainly appeal to me
> personally
> (the messaging API is better for a number of reasons than the
> older API
> and wrapping that also keeps the clients more aligned
> conceptually), I
> think it deserves a bit more debate. Specifically we have to
> explicitly
> decide as a community whether this new approach is a path we should
> pursue. I'm keen to hear the thoughts of Cliff, Aidan and other .net
> aficionados.
I'm certainly not up to Cliff's level w/ .NET but I agree with Gordon -
this new approach is more elegant and probably more maintainable.
However, nobody has discussed:
- What about the older .NET component(s)?
- How might this affect WCF?
- Has anyone thought of how to package this?
- Does it have any documentation or tests?
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[.net]: some debate please
Posted by Gordon Sim <gs...@redhat.com>.
On 05/10/2010 09:33 PM, tross@apache.org wrote:
> Author: tross
> Date: Mon May 10 20:33:19 2010
> New Revision: 942892
>
> URL: http://svn.apache.org/viewvc?rev=942892&view=rev
> Log:
> QPID-2589 - Applied patch from Chuck Rolke.
This commit adds a new component and yet another approach for .net,
specifically a .net wrapper around the c++ messaging API.
We also have a wcf client (this also uses some c++ code, but uses the
0-10 specific API plus some direct use of the internals of the client),
and two different pure c# clients for 0-8 and 0-10 respectively.
Four different options each with its own codebase isn't sensible. We
can't maintain them all and it is confusing for users.
While aspects of this latest approach certainly appeal to me personally
(the messaging API is better for a number of reasons than the older API
and wrapping that also keeps the clients more aligned conceptually), I
think it deserves a bit more debate. Specifically we have to explicitly
decide as a community whether this new approach is a path we should
pursue. I'm keen to hear the thoughts of Cliff, Aidan and other .net
aficionados.
--Gordon
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org