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: 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
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: 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: 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
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: 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: 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
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
