Re: Qpid 0.5 RC2
Issue QPID-1848 has been resolved. Regards, Andrea 2009/5/12 Andrea Gazzarini > Hi Martin, I checked the QMan archives. > There's only one problem with the qman-jmx.sh startup script for QMan JMX > Adapter : it's notworking :(No problem concerning the other scripts and > the application. > I created a JIRA issue (QPID-1848) for resolving that and I'm just going to > submit the fix. > > Regards, > Andrea > > 2009/5/11 Martin Ritchie > >> Qpid 0.5 RC2 is now ready for final testing: >> http://people.apache.org/~ritchiem/Qpid-0.5/RC2 >> (Files are uploading, give it 1hr for all artefacts to be available.) >> >> Updates are mainly packaging based, though I have updated a number of >> files for license headers as reported by RAT. The latest RAT output is >> attached here, the files that are being highlighted with unknown >> licenses are now generated files or txt files. >> >> - Updated license headers on a number of files. If we are adding a >> new file and it has a comment structure can we please ensure that we >> have the license file at the start. >> - Created new release artefacts for Java (QMan/WSDL, client-examples, >> qpid-cli) >> >> As there are a couple of artefacts that are new I will delay starting >> the vote thread until Wednesday (2009-05-13). >> >> I have verified that the: >> - packages contain the required notice/license file >> - source bundle can build the release artefacts >> - cpp broker package builds and starts on fedora 10 >> - complete java packaged broker starts up as do the associated tools. >> - java broker starts up >> - java client examples run using qpid-all.jar as the classpath >> - java Eclipse MC linux x68, OS-X start up >> - java QMan tool starts up >> - java qpid-cli tool starts up >> >> I have not investigated dotnet, ruby or python, other than there >> packaging was completed. >> >> The biggest issue I noticed was the lack of bundled documentation at >> least from the Java side. All the artefacts ship with a README which >> only details starting the broker, not ideal but something we can work >> on for our next release. >> >> Regards >> >> Martin >> -- >> Martin Ritchie >> >> >> >> - >> Apache Qpid - AMQP Messaging Implementation >> Project: http://qpid.apache.org >> Use/Interact: mailto:dev-subscr...@qpid.apache.org >> > >
[jira] Resolved: (QPID-1848) qman-jmx.sh startup script is not working
[ https://issues.apache.org/jira/browse/QPID-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Gazzarini resolved QPID-1848. Resolution: Fixed Bug has been resolved. Now the QMan JMX Adapter starts up correctly on Unix platforms. Regards, Andrea > qman-jmx.sh startup script is not working > - > > Key: QPID-1848 > URL: https://issues.apache.org/jira/browse/QPID-1848 > Project: Qpid > Issue Type: Bug > Components: Java Management : QMan >Affects Versions: 0.5 >Reporter: Andrea Gazzarini >Assignee: Andrea Gazzarini >Priority: Blocker > Fix For: 0.5 > > Original Estimate: 24h > Remaining Estimate: 24h > > The startup script for QMan (JMX Adapter) on Unix platforms is not working. > No problem for Windows version. > Regards, > Andrea -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Qpid 0.5 RC2
Hi Martin, I checked the QMan archives. There's only one problem with the qman-jmx.sh startup script for QMan JMX Adapter : it's notworking :(No problem concerning the other scripts and the application. I created a JIRA issue (QPID-1848) for resolving that and I'm just going to submit the fix. Regards, Andrea 2009/5/11 Martin Ritchie > Qpid 0.5 RC2 is now ready for final testing: > http://people.apache.org/~ritchiem/Qpid-0.5/RC2 > (Files are uploading, give it 1hr for all artefacts to be available.) > > Updates are mainly packaging based, though I have updated a number of > files for license headers as reported by RAT. The latest RAT output is > attached here, the files that are being highlighted with unknown > licenses are now generated files or txt files. > > - Updated license headers on a number of files. If we are adding a > new file and it has a comment structure can we please ensure that we > have the license file at the start. > - Created new release artefacts for Java (QMan/WSDL, client-examples, > qpid-cli) > > As there are a couple of artefacts that are new I will delay starting > the vote thread until Wednesday (2009-05-13). > > I have verified that the: > - packages contain the required notice/license file > - source bundle can build the release artefacts > - cpp broker package builds and starts on fedora 10 > - complete java packaged broker starts up as do the associated tools. > - java broker starts up > - java client examples run using qpid-all.jar as the classpath > - java Eclipse MC linux x68, OS-X start up > - java QMan tool starts up > - java qpid-cli tool starts up > > I have not investigated dotnet, ruby or python, other than there > packaging was completed. > > The biggest issue I noticed was the lack of bundled documentation at > least from the Java side. All the artefacts ship with a README which > only details starting the broker, not ideal but something we can work > on for our next release. > > Regards > > Martin > -- > Martin Ritchie > > > > - > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:dev-subscr...@qpid.apache.org >
[jira] Created: (QPID-1848) qman-jmx.sh startup script is not working
qman-jmx.sh startup script is not working - Key: QPID-1848 URL: https://issues.apache.org/jira/browse/QPID-1848 Project: Qpid Issue Type: Bug Components: Java Management : QMan Affects Versions: 0.5 Reporter: Andrea Gazzarini Assignee: Andrea Gazzarini Priority: Blocker Fix For: 0.5 The startup script for QMan (JMX Adapter) on Unix platforms is not working. No problem for Windows version. Regards, Andrea -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1847) The framing codec code for clustering is linked into qpidcommon
[ https://issues.apache.org/jira/browse/QPID-1847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708226#action_12708226 ] Andrew Stitcher commented on QPID-1847: --- When I say built into every broker and client I don't mean at link time, but rather that the resident code at run time is larger because of this unnecessary code. > The framing codec code for clustering is linked into qpidcommon > --- > > Key: QPID-1847 > URL: https://issues.apache.org/jira/browse/QPID-1847 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Client >Affects Versions: M4 >Reporter: Andrew Stitcher >Priority: Minor > > This would make sense if qpid common was a ststic library in which case it > would only be picked up by the module that wants it (cluster.so). but > currently it gets build into every broker and client which makes them > significantly larger than they need to be. > This is particularly so for the Windows port as the cluster framing code gets > built in even though we don't support any clustering on windows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Created: (QPID-1847) The framing codec code for clustering is linked into qpidcommon
The framing codec code for clustering is linked into qpidcommon --- Key: QPID-1847 URL: https://issues.apache.org/jira/browse/QPID-1847 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: M4 Reporter: Andrew Stitcher Priority: Minor This would make sense if qpid common was a ststic library in which case it would only be picked up by the module that wants it (cluster.so). but currently it gets build into every broker and client which makes them significantly larger than they need to be. This is particularly so for the Windows port as the cluster framing code gets built in even though we don't support any clustering on windows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1842) QMF-generated code doesn't export symbols
[ https://issues.apache.org/jira/browse/QPID-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708195#action_12708195 ] Andrew Stitcher commented on QPID-1842: --- With the most recent changes the only symbols that still fail are in the qmf::org::apache::qpid::acl namespace. (After some discussion with tross) I think that what should be happening (but isn't currently) is that the qmf generated code in this namespace should be linked in with the acl module itself. As fas as I can understand these symbols aren't used outside the acl module anyway. The way to do this is to modify the managment.mk/.cmake files to split the list of cpp files along namespace lines just as the .h files are split then they could be included in different lists in CMakefile.txt/Makefile.am Any other commetns Ted? > QMF-generated code doesn't export symbols > - > > Key: QPID-1842 > URL: https://issues.apache.org/jira/browse/QPID-1842 > Project: Qpid > Issue Type: Bug > Components: Qpid Managment Framework > Environment: Windows, Visual Studio >Reporter: Steve Huston > > The C++ ACL plugin fails to link on Windows because the needed QMF-generated > symbols built into the broker library are not exported. > It is possible, with little trouble, to change the qmf-gen templates to > generate the proper export declarations; however, this would cause all > generated symbols to be exported, not just the ACL-related ones. This is not > necessarily a bad thing, but I'm open to more ideas on how to accomplish this. > The wide-ranging nature of the code gen was hinted at in QPID-1274. So that's > possibly something to consider. > If I don't hear objections within a day or two, I'll go ahead and add the > exports to all generated symbols. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1843) Multiple use of single qpid::management::ManagementAgent::Singleton confusing and error-prone
[ https://issues.apache.org/jira/browse/QPID-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708064#action_12708064 ] Ted Ross commented on QPID-1843: Steve, I applied the patch and removed it from this issue. ManagementAgent::Singleton is no longer defined or used within the broker. Also, the pure-virtual ManagementAgent class is no longer referenced within the broker. The broker now has its own ManagementAgent implementation that is instantiated once by the broker and a pointer to it exposed through the getManagementAgent() method. -Ted > Multiple use of single qpid::management::ManagementAgent::Singleton confusing > and error-prone > - > > Key: QPID-1843 > URL: https://issues.apache.org/jira/browse/QPID-1843 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, Qpid Managment Framework >Affects Versions: 0.5 >Reporter: Steve Huston >Assignee: Ted Ross > Fix For: 0.6 > > > Currently the qpid/agent/ManagementAgent.h file declares the > qpid::management::ManagementAgent pure virtual class. Places where management > agent functionality is desired must derive a class from ManagementAgent at a > minimum. This is fine. However, there's also a non-virtual > ManagementAgent::Singleton class defined in ManagementAgent.h. Current > practice for this arrangement requires each place where a > ManagementAgent-derived class is defined to also reimplement (including > static class members) qpid::management::ManagementAgent::Singleton, the > implementation of which manages the new class derived from ManagementAgent. > This causes a problem because the ManagementAgent::Singleton class's member > functions must be exported from the implementing DLL. However, the > implementing DLL is not known when the class is declared and, in fact, there > may be multiple implementations. For example, the qmf-agent has an > implementation, and so does the broker. Currently, Singleton is marked as > exported from the QMF-agent library. Thus, when broker is built, it sees both > locally-defined and imported Singleton symbols. Apparantly, g++ is ok with > this and just takes the local one (even if that's not what you want, but I > digress...). > It wouldn't work to just avoid exporting the symbols, because they are needed > externally. For example, the acl plugin needs to get the broker's singleton > pointer. > One idea is to simply avoid the use of Singleton. If a instance of a > ManagementAgent-derived class is desired, just instantiate one. Or add a > method to the subclass to manage a singleton. Or whatever works for the > particular class's use cases. The point is to push the lifetime management to > the agent-derived class. > In the case of the broker, the ManagementBroker (derived from > ManagementAgent) could simply be used (or not, depending on the > disable-management setting), and a method be added to Broker to obtain the > ManagementAgent pointer, which could be a refcounted pointer since it's often > saved. Then the, for example, ManagementBroker could export the symbols it > needs, if any, in addition to the getMgmtAgent (or whatever) method. > Any other ideas on this? I can start working on the changes when we decide on > a way to go. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1731) Need to add a MS Visual Studio project to build qmf-agent
[ https://issues.apache.org/jira/browse/QPID-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708059#action_12708059 ] Steve Huston commented on QPID-1731: The Management Singleton issue was raised in JIRA-1843 and Ted Ross is working on it. Thanks for confirming you built everything - that's' good to know. > Need to add a MS Visual Studio project to build qmf-agent > - > > Key: QPID-1731 > URL: https://issues.apache.org/jira/browse/QPID-1731 > Project: Qpid > Issue Type: Improvement > Components: C++ Client >Affects Versions: 0.5 > Environment: Windows, VC9 >Reporter: Steve Huston >Assignee: Steve Huston >Priority: Minor > Fix For: 0.6 > > Attachments: qpid-1731.tar > > > Pete MacKinnon reported in QPID-1673: > "There appears to be no MS project for the qmf-agent example in the branch. > Was this intentional or an oversight?" > It hasn't yet been added for Windows. It should be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1843) Multiple use of single qpid::management::ManagementAgent::Singleton confusing and error-prone
[ https://issues.apache.org/jira/browse/QPID-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708058#action_12708058 ] Steve Huston commented on QPID-1843: Ted, I don't see a patch for this issue attached. Has it already been applied (and the issue marked 'resolved')? > Multiple use of single qpid::management::ManagementAgent::Singleton confusing > and error-prone > - > > Key: QPID-1843 > URL: https://issues.apache.org/jira/browse/QPID-1843 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, Qpid Managment Framework >Affects Versions: 0.5 >Reporter: Steve Huston >Assignee: Ted Ross > Fix For: 0.6 > > > Currently the qpid/agent/ManagementAgent.h file declares the > qpid::management::ManagementAgent pure virtual class. Places where management > agent functionality is desired must derive a class from ManagementAgent at a > minimum. This is fine. However, there's also a non-virtual > ManagementAgent::Singleton class defined in ManagementAgent.h. Current > practice for this arrangement requires each place where a > ManagementAgent-derived class is defined to also reimplement (including > static class members) qpid::management::ManagementAgent::Singleton, the > implementation of which manages the new class derived from ManagementAgent. > This causes a problem because the ManagementAgent::Singleton class's member > functions must be exported from the implementing DLL. However, the > implementing DLL is not known when the class is declared and, in fact, there > may be multiple implementations. For example, the qmf-agent has an > implementation, and so does the broker. Currently, Singleton is marked as > exported from the QMF-agent library. Thus, when broker is built, it sees both > locally-defined and imported Singleton symbols. Apparantly, g++ is ok with > this and just takes the local one (even if that's not what you want, but I > digress...). > It wouldn't work to just avoid exporting the symbols, because they are needed > externally. For example, the acl plugin needs to get the broker's singleton > pointer. > One idea is to simply avoid the use of Singleton. If a instance of a > ManagementAgent-derived class is desired, just instantiate one. Or add a > method to the subclass to manage a singleton. Or whatever works for the > particular class's use cases. The point is to push the lifetime management to > the agent-derived class. > In the case of the broker, the ManagementBroker (derived from > ManagementAgent) could simply be used (or not, depending on the > disable-management setting), and a method be added to Broker to obtain the > ManagementAgent pointer, which could be a refcounted pointer since it's often > saved. Then the, for example, ManagementBroker could export the symbols it > needs, if any, in addition to the getMgmtAgent (or whatever) method. > Any other ideas on this? I can start working on the changes when we decide on > a way to go. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-1843) Multiple use of single qpid::management::ManagementAgent::Singleton confusing and error-prone
[ https://issues.apache.org/jira/browse/QPID-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved QPID-1843. Resolution: Fixed Fix Version/s: 0.6 > Multiple use of single qpid::management::ManagementAgent::Singleton confusing > and error-prone > - > > Key: QPID-1843 > URL: https://issues.apache.org/jira/browse/QPID-1843 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, Qpid Managment Framework >Affects Versions: 0.5 >Reporter: Steve Huston >Assignee: Ted Ross > Fix For: 0.6 > > > Currently the qpid/agent/ManagementAgent.h file declares the > qpid::management::ManagementAgent pure virtual class. Places where management > agent functionality is desired must derive a class from ManagementAgent at a > minimum. This is fine. However, there's also a non-virtual > ManagementAgent::Singleton class defined in ManagementAgent.h. Current > practice for this arrangement requires each place where a > ManagementAgent-derived class is defined to also reimplement (including > static class members) qpid::management::ManagementAgent::Singleton, the > implementation of which manages the new class derived from ManagementAgent. > This causes a problem because the ManagementAgent::Singleton class's member > functions must be exported from the implementing DLL. However, the > implementing DLL is not known when the class is declared and, in fact, there > may be multiple implementations. For example, the qmf-agent has an > implementation, and so does the broker. Currently, Singleton is marked as > exported from the QMF-agent library. Thus, when broker is built, it sees both > locally-defined and imported Singleton symbols. Apparantly, g++ is ok with > this and just takes the local one (even if that's not what you want, but I > digress...). > It wouldn't work to just avoid exporting the symbols, because they are needed > externally. For example, the acl plugin needs to get the broker's singleton > pointer. > One idea is to simply avoid the use of Singleton. If a instance of a > ManagementAgent-derived class is desired, just instantiate one. Or add a > method to the subclass to manage a singleton. Or whatever works for the > particular class's use cases. The point is to push the lifetime management to > the agent-derived class. > In the case of the broker, the ManagementBroker (derived from > ManagementAgent) could simply be used (or not, depending on the > disable-management setting), and a method be added to Broker to obtain the > ManagementAgent pointer, which could be a refcounted pointer since it's often > saved. Then the, for example, ManagementBroker could export the symbols it > needs, if any, in addition to the getMgmtAgent (or whatever) method. > Any other ideas on this? I can start working on the changes when we decide on > a way to go. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1843) Multiple use of single qpid::management::ManagementAgent::Singleton confusing and error-prone
[ https://issues.apache.org/jira/browse/QPID-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated QPID-1843: --- Attachment: (was: embedded-agent.diff) > Multiple use of single qpid::management::ManagementAgent::Singleton confusing > and error-prone > - > > Key: QPID-1843 > URL: https://issues.apache.org/jira/browse/QPID-1843 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, Qpid Managment Framework >Affects Versions: 0.5 >Reporter: Steve Huston >Assignee: Ted Ross > > Currently the qpid/agent/ManagementAgent.h file declares the > qpid::management::ManagementAgent pure virtual class. Places where management > agent functionality is desired must derive a class from ManagementAgent at a > minimum. This is fine. However, there's also a non-virtual > ManagementAgent::Singleton class defined in ManagementAgent.h. Current > practice for this arrangement requires each place where a > ManagementAgent-derived class is defined to also reimplement (including > static class members) qpid::management::ManagementAgent::Singleton, the > implementation of which manages the new class derived from ManagementAgent. > This causes a problem because the ManagementAgent::Singleton class's member > functions must be exported from the implementing DLL. However, the > implementing DLL is not known when the class is declared and, in fact, there > may be multiple implementations. For example, the qmf-agent has an > implementation, and so does the broker. Currently, Singleton is marked as > exported from the QMF-agent library. Thus, when broker is built, it sees both > locally-defined and imported Singleton symbols. Apparantly, g++ is ok with > this and just takes the local one (even if that's not what you want, but I > digress...). > It wouldn't work to just avoid exporting the symbols, because they are needed > externally. For example, the acl plugin needs to get the broker's singleton > pointer. > One idea is to simply avoid the use of Singleton. If a instance of a > ManagementAgent-derived class is desired, just instantiate one. Or add a > method to the subclass to manage a singleton. Or whatever works for the > particular class's use cases. The point is to push the lifetime management to > the agent-derived class. > In the case of the broker, the ManagementBroker (derived from > ManagementAgent) could simply be used (or not, depending on the > disable-management setting), and a method be added to Broker to obtain the > ManagementAgent pointer, which could be a refcounted pointer since it's often > saved. Then the, for example, ManagementBroker could export the symbols it > needs, if any, in addition to the getMgmtAgent (or whatever) method. > Any other ideas on this? I can start working on the changes when we decide on > a way to go. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1731) Need to add a MS Visual Studio project to build qmf-agent
[ https://issues.apache.org/jira/browse/QPID-1731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708042#action_12708042 ] Pete MacKinnon commented on QPID-1731: -- Steve, I did see those warnings *on occasion* but didn't really have a good explanation for it. They appeared to be benign but feel free to raise a Jira for that if you like and I can investigate further at a lower priority. Yes, the broker was built with the changes. In fact, testing went against the built broker. > Need to add a MS Visual Studio project to build qmf-agent > - > > Key: QPID-1731 > URL: https://issues.apache.org/jira/browse/QPID-1731 > Project: Qpid > Issue Type: Improvement > Components: C++ Client >Affects Versions: 0.5 > Environment: Windows, VC9 >Reporter: Steve Huston >Assignee: Steve Huston >Priority: Minor > Fix For: 0.6 > > Attachments: qpid-1731.tar > > > Pete MacKinnon reported in QPID-1673: > "There appears to be no MS project for the qmf-agent example in the branch. > Was this intentional or an oversight?" > It hasn't yet been added for Windows. It should be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Moving QMF to a top-level directory
Ted Ross wrote: Carl Trieloff wrote: Ted Ross wrote: Good idea Carl, Here's the current structure: qpid/cpp/src/qpid/agent - C++ agent library qpid/cpp/src/qpid/console- C++ console library qpid/cpp/src/qpid/management - Common files and components for managing the broker qpid/python/qmf - Python modules qpid/ruby/lib/qpid/qmf.rb- Ruby console module qpid/cpp/managementgen - Code generation tool for C++ agent qpid/java/management/client/src/main/java/org/apache/qpid/management - QMF to JMX (QMan) Here's the proposed structure: qpid/qmf/cpp - C++ implementation of qmf components qpid/qmf/cpp/bindings - Wrapped bindings to components (Python, Ruby, C#, WCF, etc.) qpid/qmf/python- Pure Python implementations (for portability) qpid/qmf/java - Pure Java implementations qpid/qmf/windows - Windows implementations qpid/qmf/tools - CLI utilities, code generators, etc. qpid/qmf/docs - Documentation why do we need qpid/qmf/windows - Windows implementations that should be hidden under a sys directory under I have a pure C# console ready about ready to post. If we could keep qpid/qmf/dotnet or qpid/qmf/chsharp. -- bk - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
