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