RE: activemq-cpp, OpenWire protocol
February(ish) sounds about right. Of course, we'd welcome any help people might want to provide :) -Original Message- From: Bish, Tim [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 13, 2006 12:39 PM To: activemq-dev@geronimo.apache.org Subject: RE: activemq-cpp, OpenWire protocol -Original Message- From: Reptilmo [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 13, 2006 12:28 PM To: activemq-dev@geronimo.apache.org Subject: activemq-cpp, OpenWire protocol Any estimate how long before OpenWire protocol is finished or in some sort of working condition for activemq-cpp? Short answer is it'll be done when its done. Long answer is that it will probably be done sometime in February or March based on the amount of work left and the amount of time we have to spend on it. There's a lot of work going on now to mature the code base and address issues that have be found, once we get things wrapped up on that front we intend on releasing a 1.1 release with all the current fixes and then moving on to working on Openwire support more heavily. Thank you. -- View this message in context: http://www.nabble.com/activemq-cpp%2C- OpenWire-protocol-tf2815437.html#a7857297 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Activemq-cpp issues moved
Just to give everyone a heads up... Last night I moved over all of the issues related to the activemq-cpp client into the new ActiveMQ C++ JIRA Project. I've also updated the changelog on the website to apply the filter against the new project http://www.activemq.org/site/activemq-cpp-10-release.html
RE: Activemq-cpp issues moved
Excellent! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, November 17, 2006 12:01 PM To: activemq-dev@geronimo.apache.org Subject: Re: Activemq-cpp issues moved BTW.. I just added version to the space and assigned all the resolved issue to version 1.0.. If the fix for version field is properly assigned on every issue then they will properly show up on the change long and road map views of jira. On 11/17/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Just to give everyone a heads up... Last night I moved over all of the issues related to the activemq-cpp client into the new ActiveMQ C++ JIRA Project. I've also updated the changelog on the website to apply the filter against the new project http://www.activemq.org/site/activemq-cpp-10-release.html -- Regards, Hiram Blog: http://hiramchirino.com
RE: Build failed, looking for maven-jaxb2-plugin
So we have a solution to this ... Thanks to Tim Bish! It comes down to a proxy issue for https. We had to set the environment variables https.proxyHost and https.proxyPort. The proxy configuration in the maven settings.xml only seems to work for http, not https. Once we defined those, it built just fine. Hope this helps. Nate -Original Message- From: Murphree, Michael [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 11:53 AM To: Mittler, Nathan Cc: activemq-dev@geronimo.apache.org Subject: RE: Build failed, looking for maven-jaxb2-plugin Nate, I've been having the same trouble as you: https://issues.apache.org/activemq/browse/AMQ-1017. I have far less experience with Maven, though. I can get through most of the build but I get stuck there with the same error. I'm not sure what I'd actually need to do to get my local Maven repository configured manually to get past this, or if that's possible. Regards, Michael -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 8:25 AM To: activemq-dev@geronimo.apache.org Subject: Build failed, looking for maven-jaxb2-plugin A clean build of trunk (with mvn 2.0.4) is failing for me when building the XMPP module, trying to download the maven-jaxb2-plugin: https://maven2-repository.dev.java.net/nonav/repository/org/jvnet/jaxb2/ maven2/maven-jaxb2-plugin/0.1/maven-jaxb2-plugin-0.1.pom The funny thing is that I can view the pom file through a web browser, so I'm not sure what is giving Maven heartburn. I've had my Maven proxy settings set up for a while, so I'm confident that's not it. A listing of the directory https://maven2-repository.dev.java.net/nonav/repository/org/jvnet/jaxb2/ maven2/maven-jaxb2-plugin/0.1/ fails - I guess they have directory listing disabled on the server. Is anyone else having this problem ... And does anyone know how I can get past it? Thanks, Nate The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
RE: [jira] Commented: (AMQ-1017) Build of current trunk with Maven2 fails
No - I guess if you're not using a proxy it's a different issue, unfortunately. BTW - I am building successfully on WinXP. Do you think your problem could be related to the firewall on XP? I wouldn't think so, but you never know with windows :) -Original Message- From: Bernhard Wellhöfer (JIRA) [mailto:[EMAIL PROTECTED] Sent: Thursday, November 16, 2006 8:54 AM To: activemq-dev@geronimo.apache.org Subject: [jira] Commented: (AMQ-1017) Build of current trunk with Maven2 fails [ https://issues.apache.org/activemq/browse/AMQ-1017?page=comments#action_37466 ] Bernhard Wellhöfer commented on AMQ-1017: - Hello Nathan, hhmm I do not use a HTTP[s] proxy. So should I just set the host and port to an empty value? An why do I not need these settings under Debian in the same local network? Build of current trunk with Maven2 fails Key: AMQ-1017 URL: https://issues.apache.org/activemq/browse/AMQ-1017 Project: ActiveMQ Issue Type: Bug Affects Versions: 4.1.0 Environment: Windows XP, Maven 2.0.4, Java 1.5.0_06 Reporter: Bernhard Wellhöfer Priority: Critical Attachments: mvn-472933.log, mvn.log, mvn.log, mvn.log A build of a fresh checkout from https://svn.apache.org/repos/asf/incubator/activemq/trunk with Maven2 fails. See the attached log of the build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: ActiveMQ CPP Change log.
Thanks! I just ran a filter in JIRA for any closed or resolved issues in the ActiveMQ space under CMS ... After looking the ActiveMQ release pages I was able to figure it out :) I think moving forward, it might be easier to have AMQ-CPP in it's own space - that way the filter criteria gets a lot simpler - We would just have to select every resolved issue that was targeted for that particular release of AMQ-CPP. Nate -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Wednesday, November 15, 2006 12:41 PM To: activemq-dev@geronimo.apache.org Subject: ActiveMQ CPP Change log. Nathan, Nice work on putting together the activemq-cpp release page! http://activemq.com/site/activemq-cpp-10-release.html How hard was it to build that change log? Would it make it simpler if the ActiveMQ cpp stuff it's own Jira space??? -- Regards, Hiram Blog: http://hiramchirino.com
RE: Lets vote: activemq-cpp-1.0 release
Gotcha ... Will do. Thanks! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Monday, November 13, 2006 9:33 AM To: activemq-dev@geronimo.apache.org Subject: Re: Lets vote: activemq-cpp-1.0 release Hi Nathan, Actually.. you can't yet. Once the ppmc has approved a release, the release must be approved by at least 3 incubator PMC members. You should tally the vote and then start a new vote thread on the general @ incubator mailing list. On 11/13/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Great! That'll do it - thanks, guys! We'll update the website with the release. Nate -Original Message- From: Jonas Lim [mailto:[EMAIL PROTECTED] Sent: Sunday, November 12, 2006 8:36 PM To: activemq-dev@geronimo.apache.org Subject: Re: Lets vote: activemq-cpp-1.0 release +1 Regards, Jonas Timothy Bish wrote: I think it's about time we start this ball rolling, so let's take a vote on whether to call the source archive located here: http://people.apache.org/~tabish the official 1.0 release of activemq-cpp What do you think, is it time to put this one to bed? - Timothy A. Bish -- Regards, Hiram Blog: http://hiramchirino.com
Build failed, looking for maven-jaxb2-plugin
A clean build of trunk (with mvn 2.0.4) is failing for me when building the XMPP module, trying to download the maven-jaxb2-plugin: https://maven2-repository.dev.java.net/nonav/repository/org/jvnet/jaxb2/ maven2/maven-jaxb2-plugin/0.1/maven-jaxb2-plugin-0.1.pom The funny thing is that I can view the pom file through a web browser, so I'm not sure what is giving Maven heartburn. I've had my Maven proxy settings set up for a while, so I'm confident that's not it. A listing of the directory https://maven2-repository.dev.java.net/nonav/repository/org/jvnet/jaxb2/ maven2/maven-jaxb2-plugin/0.1/ fails - I guess they have directory listing disabled on the server. Is anyone else having this problem ... And does anyone know how I can get past it? Thanks, Nate
RE: ActiveMQ core test suite
That line between unit and integration tests can be gray sometimes, especially when you're unit testing things like the transport classes which require feedback from the broker. I guess you'd have to make the decision on a case-by-case basis, otherwise you'd be removing most of our tests :). One thing to consider (which would not be a quick fix) would be to move much of what we do in the setUp/teardown methods up to the constructor/destructor level of the test classes. This way allocation of expensive resources (connections, etc) would only be done once, rather than once per test method. This would be pretty painful, however, so I would opt for any quick and dirty solutions first :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Tuesday, November 07, 2006 10:23 AM To: activemq-dev@geronimo.apache.org Subject: ActiveMQ core test suite Hi folks! I've been looking at the activemq-core test suite and it keep getting bigger and bigger and takes longer and long to run. Ideally tests should only take like 5 minutes to run. What do you think we should do about it? We are currently forking each test case, so if we could avoid that it should speed it up a bit. Any other ideas? Perhaps we can classify some of the tests as being only needed for integration testing?? -- Regards, Hiram Blog: http://hiramchirino.com
RE: [activemq-cpp] It now compiles under cygwin
Yes - way to go Hiram! -Original Message- From: Bish, Tim [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 03, 2006 2:09 PM To: activemq-dev@geronimo.apache.org Subject: RE: [activemq-cpp] It now compiles under cygwin BTW - Thanks for tackling this, both Nate and Myself are stretched pretty thing right now, so the extra hand is appreciated. Hey activemq-cpp folks. activemq-cpp should now compile fine under cygwin. You may need to install all the right versions of autoconf and automake. Tim.. any chance I could convince you to switch to cygwin instead? I tried as hard as I could to use mingw under automake but I could not find the right combination of packages needed to get everything happy. The automake systems seems to be working well across several different systems now, it supports running the unit tests and generating the docs so I think we should switch to it as soon as possible. (the only system that I have not tested was Solaris) -- Regards, Hiram Blog: http://hiramchirino.com
RE: CAR plugin documentation
That makes sense. I'll give that a shot this evening - thanks! From: Guillaume Nodet [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 29, 2006 6:31 AMTo: dev@geronimo.apache.orgSubject: Re: CAR plugin documentation In your case, you need the following file ~/.m2/repository/org/apache/geronimo/configs/geronimo-gbean-deployer/1.2-SNAPSHOT/geronimo-gbean-deployer-1.2-SNAPSHOT.carI think the only way is to build Geronimo 1.2 using maven, or to put the configurations (which must be zipped) in the maven 2 local repo. By building geronimo, all files should be installed during the build process. On 8/29/06, Nathan Mittler [EMAIL PROTECTED] wrote: Thanks for the help guys! I'm almost there ... I think :). I'm getting the following error when I run "mvn clean package -e" (it fails in the package goal):...Caused by: org.apache.geronimo.kernel.config.NoSuchConfigException: org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfigurationData(SimpleConfigurationManager.java:454) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:268)I'm assuming the plugin has to be configured to point to my geronimo distribution (~/geronimo-1.2-SHAPSHOT) so that it can find the geronimo-gbean-deployer car. Is there a setting in the plugin to resolve this car? I've tried seting GERONIMO_HOME, but that didn't seem to make a difference.Thanks!Nate On 8/25/06, Guillaume Nodet [EMAIL PROTECTED] wrote: Note that this one will only work if you intend to develop plugins for G 1.2-SNAPSHOT.If you want to build plugin for G 1.1, you should compile the following one: http://svn.apache.org/repos/asf/geronimo/server/branches/1.1/car-maven-plugin/You can see some examples of using these plugins at http://svn.apache.org/repos/asf/incubator/servicemix/trunk/geronimo/ On 8/25/06, Nathan Mittler [EMAIL PROTECTED] wrote: Ah ... exactly what I was looking for! Thanks! On 8/25/06, Jason Dillon [EMAIL PROTECTED] wrote: http://geronimo.apache.org/maven/server/plugins/car-maven-plugin/ index.html--jasonOn Aug 25, 2006, at 2:22 PM, Nathan Mittler wrote: Hi guys, I've seen some posts recently about the CAR maven plugin and it seems like it would be really useful for my project's deployment needs.Is there anywhere I can go to better understand what it does and how to use it (goals, etc)?Google has failed me miserably! :) Thanks, Nate -- Cheers, Guillaume Nodet -- Cheers,Guillaume Nodet
RE: auto-generating documentation for C++ client?
Nevermind Hiram, I think I misunderstood you. That would be acceptable (and trivial). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Thursday, August 03, 2006 11:01 PM To: activemq-dev@geronimo.apache.org Subject: Re: auto-generating documentation for C++ client? On 8/3/06, Nathan Mittler [EMAIL PROTECTED] wrote: Hiram, I've updated the docs so that there's two separate directories: https://svn.apache.org/repos/asf/incubator/activemq/site/cms - This has just the cms API and https://svn.apache.org/repos/asf/incubator/activemq/site/activemq-cpp - This has the all the implementation code It's a little funky right now because I wasn't sure how to get the docs for the implementation to link to the docs for cms ... but maybe we play with it a bit and see if we can figure out how to make doxygen do that. that's great! Perhaps we just generate the cms docs again when generating the actimemq ones??? Nate On 8/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Good idea ... I'll take care of that this evening. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Thursday, August 03, 2006 12:25 PM To: activemq-dev@geronimo.apache.org Subject: Re: auto-generating documentation for C++ client? Looks great. Just a small suggestion. Perhaps the docs for the cms modules and the activemq modules should generated seperatly. Since most users will only be using the cms:: namespace 99% of the time, includeing the activemq:: docs would just make the API harder for them to follow. On 8/3/06, Bish, Tim [EMAIL PROTECTED] wrote: Looks good guys, thanks for getting that setup. - Timothy A. Bish Sensis Corporation - -Original Message- From: Nathan Mittler [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 6:14 AM To: activemq-dev@geronimo.apache.org Subject: Re: auto-generating documentation for C++ client? Awesome! Thanks. On 8/3/06, James Strachan [EMAIL PROTECTED] wrote: On 8/3/06, James Strachan [EMAIL PROTECTED] wrote: There you go... http://svn.apache.org/repos/asf/incubator/activemq/site/cm s/ hopefully in an hour or so it should show up here http://incubator.apache.org/activemq/cms/html/ Unfortunately right now Confluence is down so we can't yet edit these pages to add a link... http://incubator.apache.org/activemq/javadocs.html http://incubator.apache.org/activemq/cms.html Done e.g. http://activemq.org/site/javadocs.html -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
RE: auto-generating documentation for C++ client?
Good idea ... I'll take care of that this evening. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Thursday, August 03, 2006 12:25 PM To: activemq-dev@geronimo.apache.org Subject: Re: auto-generating documentation for C++ client? Looks great. Just a small suggestion. Perhaps the docs for the cms modules and the activemq modules should generated seperatly. Since most users will only be using the cms:: namespace 99% of the time, includeing the activemq:: docs would just make the API harder for them to follow. On 8/3/06, Bish, Tim [EMAIL PROTECTED] wrote: Looks good guys, thanks for getting that setup. - Timothy A. Bish Sensis Corporation - -Original Message- From: Nathan Mittler [mailto:[EMAIL PROTECTED] Sent: Thursday, August 03, 2006 6:14 AM To: activemq-dev@geronimo.apache.org Subject: Re: auto-generating documentation for C++ client? Awesome! Thanks. On 8/3/06, James Strachan [EMAIL PROTECTED] wrote: On 8/3/06, James Strachan [EMAIL PROTECTED] wrote: There you go... http://svn.apache.org/repos/asf/incubator/activemq/site/cms/ hopefully in an hour or so it should show up here http://incubator.apache.org/activemq/cms/html/ Unfortunately right now Confluence is down so we can't yet edit these pages to add a link... http://incubator.apache.org/activemq/javadocs.html http://incubator.apache.org/activemq/cms.html Done e.g. http://activemq.org/site/javadocs.html -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
RE: CPP Client and Temporary Topics
Right now the CPP client only supports the stomp protocol, which does not support temporary topics. So it's a limitation of the client in the fact that it only supports the stomp protocol right now. You could try one of the openwire clients, which you can get to from the C Integration page (http://www.activemq.org/site/c-integration.html). I don't have any experience with these clients, but there are others on the list that have used them in the past. The top item on our list for the activemq-cpp client is to add support for the openwire protocol, which will give it the functionality of temporary topics (among other things). Regards, Nate -Original Message- From: kevinba [mailto:[EMAIL PROTECTED] Sent: Monday, July 24, 2006 10:07 AM To: activemq-dev@geronimo.apache.org Subject: CPP Client and Temporary Topics I have a C++ client that is the server for my Java web server. Java request data from the C++ client through 1 topic. Java creates a temporary topic and sets the ReplyTo to this topic. This way the data being sent back is only received by one person, the person asking for the data. If I'm right you can't handle temporary topics at all in CPP client. You can't create a tempoary topic and you can't respond back to a request when the destination is a temporary topic. I've tried responding back and I just get an exception. I've not tried creating a temporary topic but it looks like the function just throws an exception if I followed it correctly. Is someone working on this and how long will it be before it is done? This is the only thing left so that I can switch from SonicMQ to ActiveMQ for my JMS broker. Thanks, -- View this message in context: http://www.nabble.com/CPP-Client-and-Temporary-Topics-tf199254 2.html#a5468130 Sent from the ActiveMQ - Dev forum at Nabble.com.
RE: ActiveMQ-CPP Mac changes dropped
Hey Hiram, BTW, I just googled for svn:eol-style and ran across this link http://www.apache.org/dev/svn-eol-style.txt I'm guessing I should probably have these settings before I commit? ... oops! :) Nate -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Wednesday, July 05, 2006 10:34 PM To: activemq-dev@geronimo.apache.org Subject: Re: ActiveMQ-CPP Mac changes dropped The only thing I did was use the svn propset svn:eol-style native command. So It's weird that there woudl be any loss of data. Do you got a link to jame's svn revistion? On 7/5/06, Timothy Bish [EMAIL PROTECTED] wrote: Hiram I was taking a look at the code in activemq-cpp to sync up all the changes that James had made for the Mac, and I noticed that as of 6:27pm today you had touched almost all the files, and now the changes James had made are gone. I think I got most of them into my own local SVN, but I am not 100%. I'm working on some additional things locally for the next rev. - Timothy A. Bish [EMAIL PROTECTED] -- Regards, Hiram Blog: http://hiramchirino.com
RE: AMQ production status
Hi Naveen, Comments inline ... -Original Message- From: Naveen Rawat [mailto:[EMAIL PROTECTED] Sent: Thursday, July 06, 2006 7:48 AM To: activemq-dev@geronimo.apache.org Subject: AMQ production status Hi James We have our servers in C/C++. We are trying out available open source MQ services for maintaining persistent communication with our servers through our C++ and web clients. We tried the tests available for both Stomp and Openwire and got very little success with Stomp C++ (caught up with the persistency issue) and considerable with openwire C++ (I have an issue regarding this mailed to the mailing list on 06-July-2006). Just out of curiosity, which Stomp C++ client did you try? The reason I ask is that we just submitted a replacement for the CMS client in activemq-cpp. This API does appear to have support for persistence, although I'm not sure that we have a unit test that verifies it yet. 1) Are both these C++ APIs (Stomp and Openwire) worth implementation and usage right now, or they are being made more ROBUST? The activemq-cpp is new and will be the beginning of creating a single C++ client that will support both stomp and openwire (you will be able to choose which protocol in the url). So, there is definitely activity in this area and they should continue to improve. 2) When can we see a PRODUCTION-able AMQ along with its full throttled APIs? I would try activemq-cpp, if you haven't already - it's leaps and bounds above the old CMS code! Hearty Regards Naveen Rawat Regards, Nate
subversion plugin for jira
Hey guys, are we using this? http://confluence.atlassian.com/display/JIRAEXT/JIRA+Subversion+plugin Seems like it might be a way to bridge between commits and issues. Nate
New c++ client for stomp
I have just submitted a new C++ stomp client to the activemq SVN at https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cpp/ This serves as a full blown replacement for CMS, which didn't fully implementation of the protocol. Some of the features this includes are: 1) stomp protocol (requies AMQ 4.0.1 or later for the added request/response ids) 2) JMS 1.1-like API - consumers, producers, etc. - closely follows what was done in the .NET client. 3) support for topics and queues (so far as they are supported by stomp). 4) A pluggable architecture - facilitates having swappable protocols (can use openwire or stomp without changing code) 5) meta-url syntax similar to the other libraries to support passing in options on the url string. 6) complete suite of cpp-unit tests 7) integration-level tests (requires a broker) 8) Maven 2 build (uses Mojo native plugin) 9) Support for selectors 10) Support for durable subscriptions 11) Support for transactions *BUILDING** So far, we've only built on linux and windows - so feedback would be much appreciated from you Mac and Solaris users :) We have a couple ways of building: Maven 2 and makefiles. See the readme.txt at the root for details. The Maven build uses the Mojo Native Plugin, which has some limitations that we'll eventually need to get past. For one, there seems to be linking issues on Solaris, because it's passing in a -o option to AR, which causes heartburn. Other than that, we've had Maven sucessfully building on linux/gcc and windows/msvc-2005. *EXAMPLES* The usage is pretty similar to CMS. Check out the integration tests (essentially unit tests that require an activemq broker running) at https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cpp/s rc/test-integration/ for examples of how to get up and running with activemq-cpp. TODO* 1) Merge in the openwire-cpp client as a connector in activemq-cpp. User's will be able to choose which connector they use in the URI syntax (similar to the way transports are configured in ActiveMQ). 2) Eliminate the makefiles and have everything building through Maven 3) Complete the Logging API 4) Add how to docs on the wiki 5) investigate the 999 (1000) messages bug with transactions - seems to be at the broker (not sure) 6) investigate why durable subscriptions aren't working 7) test with Hiram's latest stomp transport changes. KNOWN ISSUES* 1) Durable subscriptions don't seem to be working. The documentation reads that they are on by default, but reconnecting a client with the same client id doesn't seem to do the trick. 2) After committing a transaction, the consumer seems to stop getting messages after around 999/1000 messages. We think this is a bug at the broker, but more investigation is needed. 3) The Maven build doesn't work on Solaris - a -o is being passed into the archiver, which is unsupported. For all the tasks that CMS did, activemq-cpp should do just as well and is much better tested, so I would encourage those using CMS to make the switch. The next big step is to merge in the openwire-cpp code so that activemq-cpp is a one-stop-shop for all ActiveMQ protocols from C++. BTW - many thanks to Tim Bish for cranking out a lot of the code! Regards, Nate
RE: [activemq-user] Queue and Persistence for CMS
Arashad, Looking at the code, it appears that Tim Bish has implemented persistence in the activemq-cpp code (https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cpp/ ). This is a full-on replacement for CMS, but you'll need v4.0.1 (or later) of the broker. Unfortunately, I'm not sure that we have a use case that verifies whether or not persistence works, but you may want to give it a try. Let me know how it goes. Regards, Nate -Original Message- From: Arshad Ahamad [mailto:[EMAIL PROTECTED] Sent: Saturday, July 01, 2006 2:04 AM To: [EMAIL PROTECTED]; activemq-dev@geronimo.apache.org Subject: Re: [activemq-user] Queue and Persistence for CMS Hi James.Strachan, I am working cms(ActiveMQ-4.0) code on SuSe(Linux machine- i686-suse-linux, version 2.6.13-15.8-default) You refer me to use Queue to mentain the persistence in the cms code, but this is Outstanding Item http://svn.apache.org/repos/asf/incubator/activemq/trunk/cms/d ocs/cms_overvi ew.pdf)according to the documentation. If it is under developing by the ActiveMQ team, then my I ask you when it will develope because my work is delaying. If you have any other option to maintain the persistence Please refere me so that I can start my work. Thanks in advance Regards Arashad Ahamad
RE:
Hi Naveen, There are a couple of things that might be causing this. 1) The stomp frame ending characters have changed in recent versions of AMQ. AMQ now enforces that stomp frames end with \0\n for all commands. If you have an older version of CMS, and a fairly new version of AMQ (e.g. 4.0), they may not play nice together. 2) I have seen some deadlocking occur on compilers that don't support the PTHREAD_MUTEX_RECURSIVE type for mutexes (the code checks __USE_UNIX98 and __APPLE__ flags to make this determination. CMS requires recursive mutexes to work properly - it will deadlock otherwise. Regardless of what your particular problem is, I recommend downloading and trying out the activemq-cpp code (https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cpp/ ). It solves the mutex problem (since it doesn't use recursive mutexes) and has been tested against AMQ 4.0.1 (it actually requires 4.0.1 or greater). Give that a try and let me know how it goes. Regards, Nate -Original Message- From: Naveen Rawat [mailto:[EMAIL PROTECTED] Sent: Saturday, July 01, 2006 9:15 AM To: activemq-dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Hi there..!! I was trying out CMS OPENWIRE C++ APIs on SUSE Linux 10.0(Kernel release 2.6.13-15.8-default) Whenever I try to execute TestMain.cpp it gives the following and goes into sleep mode. Connecting to ActiveMQ broker... Opening socket to: 127.0.0.1 on port 61666 Sending command: cmd.id = 1, corr.id = -1, type = CONNECTION_INFO Received command: cmd.id = 0, corr.id = -1, type = WIRE_FORMAT_INFO Received command: cmd.id = 1, corr.id = -1, type = BROKER_INFO My AMQ Server is running as : ACTIVEMQ_HOME: /home/nrawat/incubator-activemq-4.0 Loading message broker from: xbean:activemq.xml Created MBeanServer with ID: da6bf4:10c2b32b38c:-8000:kuwix:1 INFO BrokerService - ActiveMQ 4.0 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ RMIConnectorServer started at: service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO ManagementContext - JMX consoles can connect to service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 5 x 20.0 Megs at: /home/nrawat/incubator-activemq-4.0/activemq-data/journal INFO JournalPersistenceAdapter - Journal Recovered: 0 message(s) in transactions recovered. INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61666 WARN MulticastDiscoveryAgent- brokerName not set INFO TransportConnector - Connector default Started INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61633?wireFormat=stomp INFO TransportConnector - Connector stomp Started INFO NetworkConnector - Network Connector default Started INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:kuwix-2163-1151775977128-1:0) started Hearty Regards, Naveen Rawat
RE:
Hey Hiram, I was actually thinking of the messages coming from the broker to the client - the newer version of the broker always sends a \0\n to denote the end of the frame. I'm not sure if the CMS client is sly enough to handle both cases - I think it's expecting one or the other (either \0 or \0\n). I was just throwing that out there as a possible reason that the client may freeze on a read - waiting for the trailing \n that never comes. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Monday, July 03, 2006 12:58 PM To: activemq-dev@geronimo.apache.org Subject: Re: Hi Nathan, I'm not so sure about that. I think that AMQ should support receiving a STOMP frame terminated by \0 without a subsequent \n. The STOMP spec does say that white space before a frame should be ignored. Anyways, if anybody can confirm that this is not the case, then it's a bug with how we implemented STOMP in AMQ. On 7/3/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Hi Naveen, There are a couple of things that might be causing this. 1) The stomp frame ending characters have changed in recent versions of AMQ. AMQ now enforces that stomp frames end with \0\n for all commands. If you have an older version of CMS, and a fairly new version of AMQ (e.g. 4.0), they may not play nice together. 2) I have seen some deadlocking occur on compilers that don't support the PTHREAD_MUTEX_RECURSIVE type for mutexes (the code checks __USE_UNIX98 and __APPLE__ flags to make this determination. CMS requires recursive mutexes to work properly - it will deadlock otherwise. Regardless of what your particular problem is, I recommend downloading and trying out the activemq-cpp code (https://svn.apache.org/repos/asf/incubator/activemq/trunk/activemq-cp p/ ). It solves the mutex problem (since it doesn't use recursive mutexes) and has been tested against AMQ 4.0.1 (it actually requires 4.0.1 or greater). Give that a try and let me know how it goes. Regards, Nate -Original Message- From: Naveen Rawat [mailto:[EMAIL PROTECTED] Sent: Saturday, July 01, 2006 9:15 AM To: activemq-dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Hi there..!! I was trying out CMS OPENWIRE C++ APIs on SUSE Linux 10.0(Kernel release 2.6.13-15.8-default) Whenever I try to execute TestMain.cpp it gives the following and goes into sleep mode. Connecting to ActiveMQ broker... Opening socket to: 127.0.0.1 on port 61666 Sending command: cmd.id = 1, corr.id = -1, type = CONNECTION_INFO Received command: cmd.id = 0, corr.id = -1, type = WIRE_FORMAT_INFO Received command: cmd.id = 1, corr.id = -1, type = BROKER_INFO My AMQ Server is running as : ACTIVEMQ_HOME: /home/nrawat/incubator-activemq-4.0 Loading message broker from: xbean:activemq.xml Created MBeanServer with ID: da6bf4:10c2b32b38c:-8000:kuwix:1 INFO BrokerService - ActiveMQ 4.0 JMS Message Broker (localhost) is starting INFO BrokerService - For help or more information please see: http://incubator.apache.org/activemq/ RMIConnectorServer started at: service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO ManagementContext - JMX consoles can connect to service:jmx:rmi://kuwix/jndi/rmi://localhost:1099/jmxrmi INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 5 x 20.0 Megs at: /home/nrawat/incubator-activemq-4.0/activemq-data/journal INFO JournalPersistenceAdapter - Journal Recovered: 0 message(s) in transactions recovered. INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61666 WARN MulticastDiscoveryAgent- brokerName not set INFO TransportConnector - Connector default Started INFO TransportServerThreadSupport - Listening for connections at: tcp://kuwix:61633?wireFormat=stomp INFO TransportConnector - Connector stomp Started INFO NetworkConnector - Network Connector default Started INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:kuwix-2163-1151775977128-1:0) started Hearty Regards, Naveen Rawat -- Regards, Hiram Blog: http://hiramchirino.com
New c++ library
All, Tim Bish and I are just about ready with the new C++ library. It currently will only serve as a replacement for CMS (stomp C++ client), but it's architecture supports pluggable connectors, so merging in the openwire-cpp client code should be fairly easy. Some of the features include: 1) stomp protocol (requies AMQ 4.0.1 or later for the added request/response ids) 2) JMS 1.1-like API - consumers, producers, etc. - closely follows what was done in the .NET client. 3) support for topics and queues (so far as they are supported by stomp). 4) Connector architecture - facilitates having swappable protocols (can use openwire or stomp without changing code) 5) meta-url syntax similar to the other libraries to support passing in options on the url string. 6) complete suite of cpp-unit tests 7) integration-level tests (requires a broker) 8) Maven 2 build (uses Mojo native plugin) I'd like to call this library activemq-cpp, as it will support all the JMS-like transports. Of course, we'll want to merge in the openwire-cpp code base into it early on to consolidate the two projects. My idea was to post the code at people.apache.org/~nmittler (hopefully this weekend) and let everyone take a look. I'm open to other ideas. Regards, Nate
RE: STOMP and JMSType
Excellent! I'm breathing a sigh of relief :) -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 14, 2006 8:55 AM To: activemq-dev@geronimo.apache.org Subject: Re: STOMP and JMSType On 6/14/06, Mittler, Nathan [EMAIL PROTECTED] wrote: For map messages, on the c++ side of things we would essentially have to write a schema file for the layout of a map message. The c++ stomp client would have to be coded against that schema to properly parse the message. Unfortunately, we don't have the luxury of using a tool like XStream that uses reflection ... makes you wonder why people still code in c++! =) ;) A stomp client could just expose the XML as text; then the client application can process it however it wants - as plain text or do regex on it or use some xml parser of its choosing etc. My rambling about XStream was really focussed on the Stomp transport inside the ActiveMQ broker - i.e. the stomp - JMS bridge - rather than the clients. I'd not want to force all Stomp clients to support some kinda XStream feature. I like the rule that telnet has to be a compliant Stomp cilent :) - James --- http://radio.weblogs.com/0112098/
RE: STOMP and JMSType
Sounds good to me. +1 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Tuesday, June 13, 2006 1:45 PM To: activemq-dev@geronimo.apache.org Subject: Re: STOMP and JMSType On 6/13/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Just to make clear what the proposed new hard-coded logic does: 1) If there is no content-length, it's a text message (same as before) 2) else, if there is no message type, it's a bytes message (same as before) 3) else use amq-msg-type to determine the message type So this logic is backward-compatible with the existing logic. If the client does not specify amq-msg-type, the behavior will be the same as it is now. The STOMP protocol doesn't define a mapping to a JMS system, so as far as predictability goes, the users just need to follow our logic for the mapping. They wouldn't be able to change the mapping, like they would with a pluggable framework, but they shouldn't need to. They just code their clients against the mapping that we publish online and they'll be up and running. I'm getting the feeling that the main reason for leaning toward the pluggable framework is to support a BytesMessage-only paradigm. In a STOMP-only world this probably makes sense. You're just and receiving stuff. But when you're bridging between Stomp and JMS, I'm not sure why a client would ever want this restriction. It seems like if you want BytesMessages to come out the other end, then you just follow our mapping logic to make that happen, which really is as simple as including content-length (which you would have to include for a true bytes message anyway) and leave off amq-msg-type (which you would by default). Even if you were to implement a pluggable framework, you would still need to have some sort of application metadata like the amq-msg-type header. Assuming our framework is comprised of a bunch of message transformers that go between raw bytes and ActiveMQMessages, the default transformer for the STOMP transport would do this mapping the way I've proposed above. So you wouldn't be eliminating the need for the amq-msg-type header, you'd just be pushing around the logic that uses it. So I guess I'm still not seeing the bang for the buck ... it seems like the hard-coded solution works for all cases that we've defined so far. I'd rather just get this functionality in because I think it's useful and people have been asking for it. I'm all for continuing to discuss the pluggable framework, but it seems that that is a separate issue from what I'm trying to do here (...and probably literally a separate JIRA issue). I agree. But instead calling the header 'amq-msg-type' (which does not explicitly convey that a transformation is being used), I'd like it to be called 'activemq-transformation' set to a class name of the transformation (or something that maps to a classname, like we do for our service discovery). and this would be header that is not carried with the message, it's a header that controls the send and subscribe operations. Regards, Nate -Original Message- From: Brian McCallister [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 12:20 PM To: activemq-dev@geronimo.apache.org Subject: Re: STOMP and JMSType On Jun 13, 2006, at 8:11 AM, Mittler, Nathan wrote: James, I think that's what we're proposing here. I proposed amq-msg-type, but I suppose content-type is just as good. I think Brian's main concern (Brian, correct me if I'm wrong) is that he'd like the mapping of stomp message to AMQ message type to be pluggable, not hard-coded. Actually, my first choice would be hard coded to bytes message, period, finished =) We cannot do this without breaking backwards compatibility, which I have been presuming we don't want to do. The most important thing, to me, when mapping from Stomp to JMS is to have it be very predictable. I don't want to ever have someone have a JMS client listening for stuff from Stomp and having to guess at the message type. As such, the default should be it is X. If they need some other mapping, I would suggest that they look at some kind of transformer service which republishes messages. If we are going to have more complicated mapping, I want to either make it super crippled: a default compatibility mode and a strong recommended 5.0 mode. The next step is to make mapping pluggable, but don't make a big deal out of it. As ben Laurie would say, a European style API. That is the external point of view. For the internal point of view, the cleanest implementation I can think of is to have an interface which takes a Send (or something like) and returns an ActiveMQMessage. I am quite strongly against using using application level metadata (which content-type is in Stomp and JMSType is in JMS) for mapping information. I am also quite against every client having to specify what to map the message
RE: Linking error for compiling CMS code
CMS is dependent on UNIX pthreads, so in your linker options you'll need -lpthread -Original Message- From: Arshad Ahamad [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 7:26 AM To: activemq-dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Linking error for compiling CMS code Hi all, I am compiling cmd code on SuSe(Linux machine- i686-suse-linux, version 2.6.13-15.8-default) , I am able to create the object file of this code but when I make a executable file it gives the following error /stomp/StompTransport.cpp:147: undefined reference to `pthreadpthread_join collect2: ld returned 1 exit status Please help me Thanks in advance Regards Arashad Ahamad
RE: STOMP and JMSType
Just to make clear what the proposed new hard-coded logic does: 1) If there is no content-length, it's a text message (same as before) 2) else, if there is no message type, it's a bytes message (same as before) 3) else use amq-msg-type to determine the message type So this logic is backward-compatible with the existing logic. If the client does not specify amq-msg-type, the behavior will be the same as it is now. The STOMP protocol doesn't define a mapping to a JMS system, so as far as predictability goes, the users just need to follow our logic for the mapping. They wouldn't be able to change the mapping, like they would with a pluggable framework, but they shouldn't need to. They just code their clients against the mapping that we publish online and they'll be up and running. I'm getting the feeling that the main reason for leaning toward the pluggable framework is to support a BytesMessage-only paradigm. In a STOMP-only world this probably makes sense. You're just and receiving stuff. But when you're bridging between Stomp and JMS, I'm not sure why a client would ever want this restriction. It seems like if you want BytesMessages to come out the other end, then you just follow our mapping logic to make that happen, which really is as simple as including content-length (which you would have to include for a true bytes message anyway) and leave off amq-msg-type (which you would by default). Even if you were to implement a pluggable framework, you would still need to have some sort of application metadata like the amq-msg-type header. Assuming our framework is comprised of a bunch of message transformers that go between raw bytes and ActiveMQMessages, the default transformer for the STOMP transport would do this mapping the way I've proposed above. So you wouldn't be eliminating the need for the amq-msg-type header, you'd just be pushing around the logic that uses it. So I guess I'm still not seeing the bang for the buck ... it seems like the hard-coded solution works for all cases that we've defined so far. I'd rather just get this functionality in because I think it's useful and people have been asking for it. I'm all for continuing to discuss the pluggable framework, but it seems that that is a separate issue from what I'm trying to do here (...and probably literally a separate JIRA issue). Regards, Nate -Original Message- From: Brian McCallister [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 13, 2006 12:20 PM To: activemq-dev@geronimo.apache.org Subject: Re: STOMP and JMSType On Jun 13, 2006, at 8:11 AM, Mittler, Nathan wrote: James, I think that's what we're proposing here. I proposed amq-msg-type, but I suppose content-type is just as good. I think Brian's main concern (Brian, correct me if I'm wrong) is that he'd like the mapping of stomp message to AMQ message type to be pluggable, not hard-coded. Actually, my first choice would be hard coded to bytes message, period, finished =) We cannot do this without breaking backwards compatibility, which I have been presuming we don't want to do. The most important thing, to me, when mapping from Stomp to JMS is to have it be very predictable. I don't want to ever have someone have a JMS client listening for stuff from Stomp and having to guess at the message type. As such, the default should be it is X. If they need some other mapping, I would suggest that they look at some kind of transformer service which republishes messages. If we are going to have more complicated mapping, I want to either make it super crippled: a default compatibility mode and a strong recommended 5.0 mode. The next step is to make mapping pluggable, but don't make a big deal out of it. As ben Laurie would say, a European style API. That is the external point of view. For the internal point of view, the cleanest implementation I can think of is to have an interface which takes a Send (or something like) and returns an ActiveMQMessage. I am quite strongly against using using application level metadata (which content-type is in Stomp and JMSType is in JMS) for mapping information. I am also quite against every client having to specify what to map the message to as the client should be able to be independent of the particular implementation. I think it is a very bad idea to require the client to add the mapping to every message. -Brian
RE: STOMP and connect/connected handshake
There is already a correlation-id header defined in the AMQ extensions: http://www.activemq.org/site/stomp.html - I was trying to reuse this header for the connect handshake. I don't feel that strongly one way or the other. The name response-id is fine - we'd just have to add another header to our list of extensions (we'd have to do that for the command-id header anyway). Nate -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Monday, June 12, 2006 10:05 AM To: activemq-dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Re: STOMP and connect/connected handshake Cross posting to the stomp mailing list too since someone there might have some input on this. I like the idea about supporting a command-id header. I might prefer the correlation header to be called response-id instead of correlation-id. -- Forwarded message -- From: Nathan Mittler [EMAIL PROTECTED] Date: Jun 12, 2006 6:13 AM Subject: STOMP and connect/connected handshake To: activemq-dev@geronimo.apache.org For the new activemq-cpp library, we need to extend the STOMP connect/connected handshake so that we get back a correlation-id for our response correlator. To do this, we need to send something in the connect request that contains a client-defined command-id. My first thought was to just reuse the message-id header, but that is typically reserved for cases when a client is expecting to acknowledge a message. So rather than risk breaking that paradigm, I created a new header command-id that is just used on the connect message. When the broker receives a connect request with a command-id header, it creates a connected response with a correlation-id set to the command-id of the original request. This way the client can treat the handshake as a true request/response. Does anyone see any problems with adding this to the broker? Regards, Nate -- Regards, Hiram
RE: [stomp-dev] RE: STOMP and connect/connected handshake
Agreed. So let's go with a new set of headers. I propose the following: request-id (goes in any STOMP client-broker request command ... currently only CONNECT) response-id (goes in any STOMP client-broker response command ... currently only CONNECTED) I've changed command-id to request-id so that it's clearer that the two headers are related. How does this sound? Nate -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 10:28 AM To: [EMAIL PROTECTED] Subject: Re: [stomp-dev] RE: STOMP and connect/connected handshake FWIW the correlation-id currently maps to JMSCorrelationID - but is only used on JMS messages rather than on commands like CONNECT etc. Though the JMSCorrelationID is often an out of band correlation; rather than correlating a request stomp command to a stomp response; so maybe another header name would avoid confusion? On 6/12/06, Mittler, Nathan [EMAIL PROTECTED] wrote: There is already a correlation-id header defined in the AMQ extensions: http://www.activemq.org/site/stomp.html - I was trying to reuse this header for the connect handshake. I don't feel that strongly one way or the other. The name response-id is fine - we'd just have to add another header to our list of extensions (we'd have to do that for the command-id header anyway). Nate -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Monday, June 12, 2006 10:05 AM To: activemq-dev@geronimo.apache.org; [EMAIL PROTECTED] Subject: Re: STOMP and connect/connected handshake Cross posting to the stomp mailing list too since someone there might have some input on this. I like the idea about supporting a command-id header. I might prefer the correlation header to be called response-id instead of correlation-id. -- Forwarded message -- From: Nathan Mittler [EMAIL PROTECTED] Date: Jun 12, 2006 6:13 AM Subject: STOMP and connect/connected handshake To: activemq-dev@geronimo.apache.org For the new activemq-cpp library, we need to extend the STOMP connect/connected handshake so that we get back a correlation-id for our response correlator. To do this, we need to send something in the connect request that contains a client-defined command-id. My first thought was to just reuse the message-id header, but that is typically reserved for cases when a client is expecting to acknowledge a message. So rather than risk breaking that paradigm, I created a new header command-id that is just used on the connect message. When the broker receives a connect request with a command-id header, it creates a connected response with a correlation-id set to the command-id of the original request. This way the client can treat the handshake as a true request/response. Does anyone see any problems with adding this to the broker? Regards, Nate -- Regards, Hiram - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email -- James --- http://radio.weblogs.com/0112098/ - To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
AMQ-445
Hiram, This issue is for an erroneous line feed in the STOMP commands from the broker. My understanding was that you intended to add the extra carriage return in the commands. If this is the case, can we just close this issue? Regards, Nate
permission
I don't seem to have the permission to assign issues to myself. Is there some process for getting issues assigned, or should I just be able to assign myself any issues I want? Thanks, Nate
RE: permission
Excellent - all set. Thanks! -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 2:45 PM To: activemq-dev@geronimo.apache.org Subject: Re: permission On 6/7/06, Mittler, Nathan [EMAIL PROTECTED] wrote: I don't seem to have the permission to assign issues to myself. Is there some process for getting issues assigned, or should I just be able to assign myself any issues I want? Sorry about that. Its described in the fine print near the bottom of this page - so you did exactly the right thing :) http://incubator.apache.org/activemq/contributing.html basically one of the committers need to grant you karma in JIRA. Have done it now, you should be all set (sometimes you need to log out in again to refresh your karma) -- James --- http://radio.weblogs.com/0112098/
RE: Stomp and TextMessage
Re-posting to the dev list... -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: Friday, June 02, 2006 7:21 AM To: activemq-users@geronimo.apache.org Subject: RE: Stomp and TextMessage So, here's my impression of what we need to do (feel free to make mods)... 1) The stomp transport should always add the content-length header to out-going messages, regardless of content-type or whether or not a content-length was provided on the incoming message. 2) The stomp transport should handle in-coming messages with a content-type header, and should pass that through. 3) If a message comes in without a content-length or a content-type, it should just be assumed a TextMessage. This way we can use the terminating null character as the delimiter. If we're in agreement as to what needs to be done, I'll capture this in a JIRA issue. Regards, Nate -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Thursday, June 01, 2006 7:32 AM To: activemq-users@geronimo.apache.org Subject: Re: Stomp and TextMessage Agreed - FWIW we should probably add the content-type handling to Stomp support so folks could explicitly specify its MIME type etc On 5/31/06, Nathan Mittler [EMAIL PROTECTED] wrote: Hi, I think if you leave off the content-length header, it will be interpreted as a text message. Regards, Nate On 5/31/06, wilkesj [EMAIL PROTECTED] wrote: I'm try to send a TextMessage from a ruby producer to Java consumer. The message is being seen as a BytesMessage on the Java side. I've tried setting the type header to TextMessage, javax.jms.TextMessage and org.apache.activemq.commands.ActiveMQTextMessage. How do force it to be a TextMessage? Thanks, Wilkes -- View this message in context: http://www.nabble.com/Stomp+and+TextMessage-t1712841.html#a4650956 Sent from the ActiveMQ - User forum at Nabble.com. -- James --- http://radio.weblogs.com/0112098/
RE: CMS supports bytes messages
Hey Hiram, It's surprising that OS X doesn't support recursive locks - I thought they were a standard part of pthreads. Even more surprising is when you try to lock twice from the same thread, it deadlocks itself :) I am in total agreement about sprinkling #ifdefs around the code - it's ugly and we'll have to keep tweaking them to support new platforms. But I don't think there is a way that we can get rid of them - it's just one of the many nasty parts of coding in C++. Even with autoconf you still have to have them there - autoconf just picks which ones to enable based on your environment. I'm definitely open to suggestions. Regards, Nate -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Tuesday, April 25, 2006 11:48 AM To: activemq-dev@geronimo.apache.org Subject: Re: CMS supports bytes messages Hi Nathan, I assume you've committed that patch to SVN by now. I was just testing the latest cms against the latest activemq on OS X and ran into an issue where the client was hanging in the StompTransport::addMessageListener call. Root cause: the mutex being used did not seem to support recursive locking. The following patch fixes the issue for me. I'll commit it as soon as SVN starts working again. I'm not feeling very good about sprinkling all these if defs around the code. I'm sure we are going to have to update these constantly as we support more platforms. Would using autoconfig help us with these issues? Index: activemqcms/src/activemq/concurrent/Mutex.h === --- activemqcms/src/activemq/concurrent/Mutex.h (revision 396884) +++ activemqcms/src/activemq/concurrent/Mutex.h (working copy) @@ -47,9 +47,9 @@ pthread_mutexattr_t attributes; pthread_mutexattr_init( attributes ); -#ifdef __USE_UNIX98 + #if defined(__USE_UNIX98) || defined(__APPLE__) pthread_mutexattr_settype( attributes, PTHREAD_MUTEX_RECURSIVE ); -#endif + #endif // Initialize the mutex. pthread_mutex_init( mutex, attributes ); On 4/23/06, Nathan Mittler [EMAIL PROTECTED] wrote: I know a few of people were waiting for feedback on this - so I'm sending to both lists. I've just submitted a couple of patches to the stomp C++ client (CMS). One fixes the way it was handling the broker url, and the other fixes the handling of the bytes message. It all looks good now - I tested against the April 19th incubator snapshot of AMQ. You'll need a recent version of the broker as there have been a few patches made on the stomp interface. Regards, Nate -- Regards, Hiram
RE: openwire-cpp question
Hi Mats, Is the code in svn your latest? I remember you including unit tests and makefiles at some point - did these get lost when the last patch was applied? -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 11:08 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question There is no test stub either. I am wondering if someone ever tested it? Vik -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 11:01 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question Hmm ... that surprises me - I know the openwire-cpp team had included makefiles in the past. I believe the code should support linux, windows, OSX. Does anyone know where the makefiles are? -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 10:08 AM To: activemq-dev@geronimo.apache.org Subject: RE: openwire-cpp question Hey Nate, I don't see any make file or something in there? Do you have any idea what O/S version and C++ complier this code recommends? Thanks! Vik -Original Message- From: Nathan Mittler [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 6:16 AM To: activemq-dev@geronimo.apache.org Subject: Re: openwire-cpp question The latter - It's a client-side library. The same is true for the Stomp CMS lib and the openwire .NET lib. Regards, Nate On 4/16/06, vik Dhawan [EMAIL PROTECTED] wrote: I wanted to know the use of Development branch on SVN at http://svn.apache.org/repos/asf/incubator/activemq/trunk/openwire-cpp/ Is this a C++ implementation of ActiveMQ? is it complete? or is it can be used as a C++ library so some application can use classes in this library to connect to a remote AMQ server? Thanks! -- View this message in context: http://www.nabble.com/openwire-cpp-question-t1459989.html#a3945792 Sent from the ActiveMQ - Dev forum at Nabble.com.
RE: STOMP bytes messages
Great - keep me posted. At this point, I'll be happy just to see data coming back for the bytes message ... no guarantees as to whether the CMS client processes it correctly :) Regards, Nate -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Monday, April 17, 2006 11:45 AM To: activemq-dev@geronimo.apache.org Subject: Re: STOMP bytes messages Hi Nathan, Yep. found a bunch of issues. Next up is trying your c++ client. Regards, Hiram
RE: STOMP bytes messages
Correct. It's currently an incomplete implementation of STOMP - Queues and Transactions are currently missing ... but will be added shortly. Nate -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 1:42 PM To: activemq-dev@geronimo.apache.org Subject: RE: STOMP bytes messages Nate, This code doesn't support Queues, right? Thanks! Vik -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 12:58 PM To: activemq-dev@geronimo.apache.org Subject: RE: STOMP bytes messages The CMS STOMP client code is here https://svn.apache.org/repos/asf/incubator/activemq/trunk/cms/ I'm currently in the middle of working out a couple of issues (with the help of Hiram), but I'm at work and don't have access to that code at the moment. I should have those fixes posed in a few days or so. Regards, Nate -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 12:17 PM To: activemq-dev@geronimo.apache.org Subject: RE: STOMP bytes messages Hey Nate, Where can I get latest working code for your CMS client? Thanks! Vik -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 12:10 PM To: activemq-dev@geronimo.apache.org Subject: RE: STOMP bytes messages Great - keep me posted. At this point, I'll be happy just to see data coming back for the bytes message ... no guarantees as to whether the CMS client processes it correctly :) Regards, Nate -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Monday, April 17, 2006 11:45 AM To: activemq-dev@geronimo.apache.org Subject: Re: STOMP bytes messages Hi Nathan, Yep. found a bunch of issues. Next up is trying your c++ client. Regards, Hiram
RE: STOMP bytes messages
Hi Vik, We're not quite there yet for integrating CMS and Openwire. For now, you just have to pick your poison: CMS (stomp) - or the openwire-cpp client. Regards, Nate -Original Message- From: Dhawan, Vikram (LNG-DAY) [mailto:[EMAIL PROTECTED] Sent: Monday, April 17, 2006 1:36 PM To: activemq-dev@geronimo.apache.org Subject: RE: STOMP bytes messages Thanks Nate, I will try to build it on Solaris and wait for your fixes. I am just wondering where we are maintaining CMS + Openwire integration. Thanks! Vik
RE: STOMP bytes messages
Oops ... sorry about that :). I'm at work right now and don't have access to the code - I'll get it to you this evening. Do you have an eclipse environment with the CDT for building C++ projects? ... otherwise I can throw some makefiles together if that's easier for you. Unfortunately, the current version of the code only works with a pthread environment - hopefully you're not on windoze :). Nate -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: Friday, April 14, 2006 11:53 AM To: activemq-dev@geronimo.apache.org Subject: Re: STOMP bytes messages Howdy.. now eclipse project files were included in the tar :( On 4/14/06, Hiram Chirino [EMAIL PROTECTED] wrote: yep got.. just got a little swamped. Will look into it asap. On 4/14/06, Nathan Mittler [EMAIL PROTECTED] wrote: Hey Hiram, Just wanted to see if you received the code I sent you (the first try was rejected by the server because of the file size). Let me know if you have any trouble compiling/etc. Nate -- Regards, Hiram -- Regards, Hiram
RE: Regarding feedback on OpenWire C++ client
Please define the interfaces that you want to be SP-free!
I'm with Hiram ... I think the entire API should be SP-free. The less
the users have to see SPs, the better.
It's all about the user and helping them come up to speed and use the
api
as quickly and painlessly as possible. I understand that in these
cases
you're passing a pointer and not copying, but it complicates the user
interface when the person just wants to pass in a string. They
shouldn't
have to create a string on the heap an then wrap it in a smart pointer
to
just call a function.
Just a quick note, this is not necessary with the current design of
accepting const char* and returning pstring. The user can easily
extract the const char from the SP string if wanted.
But then you lose the symmetry of the getters and setters ... the setter
should take the same type that the getter returns. IMHO, it seems
strange to have the setter take a char* and then the getter returns a
smart pointer.
Class Xxx {
std::string name;
void setName (const std::string name) {
this-name = name;
}
const std::string getName () const {
return this-name;
}
};
Shall we agree on the one above?
Regards,
Mats David
Regards,
Nate
RE: AMQ C#/C++ client refactoring suggestion
Ok, I've created a jira issue and attached my code. http://jira.activemq.org/jira/browse/AMQ-620 I've put modified versions of the groovy scripts at the root dir. They still need a few changes, such as the use of undefined classes (e.g. Object). Let me know how the merge goes. Regards, Nate -Original Message- From: David Fahlander [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 08, 2006 11:18 AM To: activemq-dev@geronimo.apache.org Subject: RE: AMQ C#/C++ client refactoring suggestion Don't think we have a jira issue, but I'm not sure. I'm a little new in the project and Mats is ill but will hopefully be back soon to help me into the project routines... :-/ So maybe it's best if you open a new issue... /David -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: den 8 mars 2006 15:57 To: activemq-dev@geronimo.apache.org Subject: RE: AMQ C#/C++ client refactoring suggestion I have noted the virtual destructor problems as well and have added the virtual destructor to (I believe) all the classes. I'll post what I've done so you can start merging it in with your code. Do you have an open jira issue that I could post to? ... I'd hate to open a new issue for every posting. Nate -Original Message- From: David Fahlander [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 08, 2006 9:34 AM To: activemq-dev@geronimo.apache.org Subject: RE: AMQ C#/C++ client refactoring suggestion It's nice to hear that it was easy to port. Your work is of great interest for us. We are currently working on updating the code to correspond to the latest C# version. Please let us know your changes. There is also another issue, which is that all the interfaces lacks of a virtual destructor (easily fixed by just adding such on each interface (struct)). Mats and I will soon send a patch with our updates as well. David -Original Message- From: Nathan Mittler [mailto:[EMAIL PROTECTED] Sent: den 7 mars 2006 02:58 To: activemq-dev@geronimo.apache.org Subject: Re: AMQ C#/C++ client refactoring suggestion Mats, I've made quite a few fixes and almost have the code building clean on linux. The remaining issues involve the autogenerated code in the command/marshal directories, as well as the use of the smart pointers (p.hpp). The main smart pointer issue seems to be in the area of dynamically casting the pointer type to a derived type. If you're interested in seeing what I've done so far, I can post the code to a jira issue, otherwise I'll just keep working on the issues. Regards, Nate On 3/6/06, Mittler, Nathan [EMAIL PROTECTED] wrote: Thanks, Mats - I'll work on getting it compiling on linux and share my findings. Regards, Nate -Original Message- From: Mats Forslöf [mailto:[EMAIL PROTECTED] ] Sent: Monday, March 06, 2006 10:02 AM To: activemq-dev@geronimo.apache.org Subject: RE: AMQ C#/C++ client refactoring suggestion Yes, both the command and marshalling code is auto generated so the marshalling part must be moved into the command generation if we make the change. We're using Windoze for development at the moment but the code are prepared for *nix platforms. However we havn't had an opportunity yet to test it on those platforms, it should require only minor tweaks to make it compile though. Note however that the code is incomplete for functional tests at the moment but it should compile. If you can help out with this it would be great. Also, you need the Apache Portable Runtime 1.22 library to make it compile. Regards, Mats -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: den 6 mars 2006 15:23 To: activemq-dev@geronimo.apache.org Subject: RE: AMQ C#/C++ client refactoring suggestion I'm still coming up to speed on the C#/C++ client so I'm not prepared just yet to offer suggestions on architecture (at least, probably nothing terribly worthwhile). At the surface, what you're proposing makes sense. The one question I have is: how does this affect code generation? Are we currently auto generating both the marshalling and command code? If so, it seems like consolidating would make the set of groovy scripts smaller, which would be a good thing. BTW, I've been having trouble compiling the openwire-cpp code. I'm on Linux with gcc 4.0.0. Have you been able to get the code compiling? Thanks, Nate -Original Message- From: Mats Forslöf [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 8:09 AM To: activemq-dev@geronimo.apache.org Subject: RE: AMQ C#/C++ client refactoring suggestion Hi Nate, Thanks, that is an excellent suggestion, using a generic ProtocolFormat would do the trick. What do think otherwise, any other suggestions on how we better could prepare for the upcoming merge!? Regards, Mats -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: den 6 mars 2006 13:52 To: activemq-dev@geronimo.apache.org Subject: RE
RE: AMQ C#/C++ client refactoring suggestion
I'm still coming up to speed on the C#/C++ client so I'm not prepared just yet to offer suggestions on architecture (at least, probably nothing terribly worthwhile). At the surface, what you're proposing makes sense. The one question I have is: how does this affect code generation? Are we currently auto generating both the marshalling and command code? If so, it seems like consolidating would make the set of groovy scripts smaller, which would be a good thing. BTW, I've been having trouble compiling the openwire-cpp code. I'm on Linux with gcc 4.0.0. Have you been able to get the code compiling? Thanks, Nate -Original Message- From: Mats Forslöf [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 8:09 AM To: activemq-dev@geronimo.apache.org Subject: RE: AMQ C#/C++ client refactoring suggestion Hi Nate, Thanks, that is an excellent suggestion, using a generic ProtocolFormat would do the trick. What do think otherwise, any other suggestions on how we better could prepare for the upcoming merge!? Regards, Mats -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: den 6 mars 2006 13:52 To: activemq-dev@geronimo.apache.org Subject: RE: AMQ C#/C++ client refactoring suggestion Hi Mats, One thing to keep in mind is that we're going to start merging our efforts in the future (at least on the C++ side). I believe that means (please correct me if I'm wrong) that what is currently the openwire c++ client will eventually be extended to support other protocols (such as Stomp). If that's the case, adding protocol-specific marshalling methods to the Commands may get hairy. Perhaps rather than the marshal/unmarshall methods taking an OpenWireFormat object, they could take a more generic type, such as a ProtocolFormat, for example? This way, the Command interface could be reused across protocols and the higher-level code could eventually be reworked such that it doesn't care about which protocol it's using. Regards, Nate -Original Message- From: Mats Forslöf [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 7:05 AM To: activemq-dev@geronimo.apache.org Subject: AMQ C#/C++ client refactoring suggestion The marshalling is currently done by a set of stand-alone objects inherited from BaseDataStreamMarshaller or BaseCommandMarshaller. An alternative design would be to let each command itself be marshall aware, that is, have them implement a marshalling interface that has two methods; marshal and unmarshal. One of the parameters to those methods would be OpenWireFormat, the command calls marshall/unmarshall on the OpenWireFormat object for each command attribute. OpenWireFormat then performs the actual marshalling by a helper class called DataStreamMarshaller and depending on what the OpenWireFormat attribute tightEncoding is set to OpenWireFormat calls either tight or loose marshalling. The benefit of this would be less code and the control of tight/loose marshalling is done in one place. Please let me know what you think, I may have missed something that makes this unsuitable. Regards, Mats
RE: AMQ C#/C++ client refactoring suggestion
Thanks, Mats - I'll work on getting it compiling on linux and share my findings. Regards, Nate -Original Message- From: Mats Forslöf [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 10:02 AM To: activemq-dev@geronimo.apache.org Subject: RE: AMQ C#/C++ client refactoring suggestion Yes, both the command and marshalling code is auto generated so the marshalling part must be moved into the command generation if we make the change. We're using Windoze for development at the moment but the code are prepared for *nix platforms. However we havn't had an opportunity yet to test it on those platforms, it should require only minor tweaks to make it compile though. Note however that the code is incomplete for functional tests at the moment but it should compile. If you can help out with this it would be great. Also, you need the Apache Portable Runtime 1.22 library to make it compile. Regards, Mats -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: den 6 mars 2006 15:23 To: activemq-dev@geronimo.apache.org Subject: RE: AMQ C#/C++ client refactoring suggestion I'm still coming up to speed on the C#/C++ client so I'm not prepared just yet to offer suggestions on architecture (at least, probably nothing terribly worthwhile). At the surface, what you're proposing makes sense. The one question I have is: how does this affect code generation? Are we currently auto generating both the marshalling and command code? If so, it seems like consolidating would make the set of groovy scripts smaller, which would be a good thing. BTW, I've been having trouble compiling the openwire-cpp code. I'm on Linux with gcc 4.0.0. Have you been able to get the code compiling? Thanks, Nate -Original Message- From: Mats Forslöf [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 8:09 AM To: activemq-dev@geronimo.apache.org Subject: RE: AMQ C#/C++ client refactoring suggestion Hi Nate, Thanks, that is an excellent suggestion, using a generic ProtocolFormat would do the trick. What do think otherwise, any other suggestions on how we better could prepare for the upcoming merge!? Regards, Mats -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: den 6 mars 2006 13:52 To: activemq-dev@geronimo.apache.org Subject: RE: AMQ C#/C++ client refactoring suggestion Hi Mats, One thing to keep in mind is that we're going to start merging our efforts in the future (at least on the C++ side). I believe that means (please correct me if I'm wrong) that what is currently the openwire c++ client will eventually be extended to support other protocols (such as Stomp). If that's the case, adding protocol-specific marshalling methods to the Commands may get hairy. Perhaps rather than the marshal/unmarshall methods taking an OpenWireFormat object, they could take a more generic type, such as a ProtocolFormat, for example? This way, the Command interface could be reused across protocols and the higher-level code could eventually be reworked such that it doesn't care about which protocol it's using. Regards, Nate -Original Message- From: Mats Forslöf [mailto:[EMAIL PROTECTED] Sent: Monday, March 06, 2006 7:05 AM To: activemq-dev@geronimo.apache.org Subject: AMQ C#/C++ client refactoring suggestion The marshalling is currently done by a set of stand-alone objects inherited from BaseDataStreamMarshaller or BaseCommandMarshaller. An alternative design would be to let each command itself be marshall aware, that is, have them implement a marshalling interface that has two methods; marshal and unmarshal. One of the parameters to those methods would be OpenWireFormat, the command calls marshall/unmarshall on the OpenWireFormat object for each command attribute. OpenWireFormat then performs the actual marshalling by a helper class called DataStreamMarshaller and depending on what the OpenWireFormat attribute tightEncoding is set to OpenWireFormat calls either tight or loose marshalling. The benefit of this would be less code and the control of tight/loose marshalling is done in one place. Please let me know what you think, I may have missed something that makes this unsuitable. Regards, Mats
RE: OpenWire.Net is feature complete
James, It was a proxy issue ... thanks for the help. -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 28, 2006 9:43 AM To: activemq-dev@geronimo.apache.org Subject: Re: OpenWire.Net is feature complete I'm wondering if its a firewall issue blocking the SSH port (443 I think). I've just ran that command fine... svn co https://svn.apache.org/repos/asf/incubator/activemq/trunk/ You could try to use http for an anonymous checkout. svn co http://svn.apache.org/repos/asf/incubator/activemq/trunk/ which should use port 80 to avoid any firewall issues On 28 Feb 2006, at 14:12, Mittler, Nathan wrote: I'm having problems checking out from svn (in cygwin) ... bash-3.00$ svn co https://svn.apache.org/repos/asf/incubator/activemq/trunk/ svn: PROPFIND request failed on '/repos/asf/incubator/activemq/trunk' svn: PROPFIND of '/repos/asf/incubator/activemq/trunk': could not connect to server (https://svn.apache.org) I've also tried svn://svn.apache.org/repos/asf/incubator/activemq/ trunk/ I haven't ruled out that it's an internal firewall issue yet, but I can browse the repository in firefox without issue. Any ideas? Regards, Nate -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 28, 2006 7:49 AM To: activemq-dev@geronimo.apache.org Subject: OpenWire.Net is feature complete Just a heads up. OpenWire.Net now supports JMS transactions along with all the various forms of Receive*() and asynchronous receive (using a MessageListener) so its pretty much feature complete. More info here http://docs.codehaus.org/display/ACTIVEMQ/OpenWire+dotNet It could use more testing and test cases to ensure that all the features are complete; the transaction tests are quite good but we could use some more tests. Currently OpenWire.Net supports all of the JMS features apart from XA support (which requires integration with MS DTC). James --- http://radio.weblogs.com/0112098/ James --- http://radio.weblogs.com/0112098/
RE: [activemq-dev] c++ api for activemq
I've have posted my code under JIRA issue AMQ-517 (under ActiveMQ/JMS Client). -Original Message- From: Mittler, Nathan Sent: Tuesday, January 31, 2006 9:02 AM To: '[EMAIL PROTECTED]'; activemq-dev@geronimo.apache.org Subject: RE: [activemq-dev] c++ api for activemq I'm sending to both developer lists, so my apologies if you receive this twice. Attached is my first cut at CMS (C++ Message Service) with a Stomp client. The idea is that CMS is the API (like JMS) and any messaging protocol can be used behind it (Stomp, OpenWire, etc). The docs folder contains the doxygen html for the source as well as a pdf document that gives a high-level overview. Nate
