RE: openwire C++ client
Nathan, in point 3, you certainly have a point. Even though I've been conscious about the internal structure of C++ objects, the fact that making an up-cast to one of multiple base classes needs ptr adjustment (as static_cast and dynamic_cast does), I have been missing this part when implementing the p_cast function. The reason why using void* is to be able to reuse classes internal refcounting mechanism if such is present, but attach an own refcounter where not. For example, the p template is compatible with both pint and pIUnknown. Thanks for seeing the problem. We will need to update the IFR code in order for the client to work properly where p_cast is used. I'll look into this and update the IFR. Mats and I will continue with testing and fixing issues. David -Original Message- From: Nathan Mittler [mailto:[EMAIL PROTECTED] Sent: den 26 mars 2006 23:12 To: activemq-dev@geronimo.apache.org Subject: openwire C++ client I've taken a closer look at the openwire C++ client this weekend and noticed a few things ... 1) I think there are a few cases where we could reduce the usage of smart pointers. One instance where I think smart pointer usage is questionable is when openwire is referencing an object that it doesn't control. For example, when my code declares a class that is an IMessageListener, it seems strange that this should be passed in as a smart pointer to openwire functions. Openwire doesn't control the lifetime of this object, so I don't believe it should be referencing it in a managed way. Another case where smart pointers could be avoided is strings. If all string member variables are std::strings, then the setXXX method could just take a const char* and the const getXXX method could simply return a const char* (which would be the value returned from the mystr.c_str() method). This makes for a much simpler and symmetric API. 2) ITextMessage should extend IMessage It seems that the ITextMessage class was at one time derived from IMessage, but it is commented out (probably to get through compilation :-) ). If you try to call send() on the MessagePublisher class with an ITextMessage, the code won't compile. I've gotten around this by making ITextMessage extend IMessage - the trick is that when you do this, ActiveMQTextMessage gets IMessage from two branches. In one branch, it gets the methods from IMessage implemented for it ( by ActiveMQMessage) and in the other branch (ITextMessage), it doesn't. So you have to have ActiveMQTextMessage implement all the methods from the IMessage interface and delegate them to the ActiveMQMessage base class. This seems to do the trick. 3) It seems that the smart pointer code should be using dynamic_cast rather than reinterpret cast. I seem to remember times where a dynamic_cast returned a slightly different address (in some cases). If this is the case, it could be very dangerous to use reinterpret_cast everywhere since it just takes the same pointer and treats its address as the other type (corrupting the references to the object). This could lead to strange bugs that are difficult to track down. The other problem is in the fact that the internal pointer is a void* rather than a T*. This complicates debugging, because the debugger sees an internal pointer, but doesn't look inside since it doesn't know what type it really is. 4) I'm not seeing an ExceptionListener equivalent. Am I missing something? 5) I got a small sample app compiling, but I'm getting a segfault when creating a session (could certainly be user error - a code snippet is below). Here's the stack dump: Thread [1] (Suspended: Signal 'SIGSEGV' received. Description: Segmentation fault.) 12 apache::activemq::client::command::ConnectionInfo::marshal() at src/command/ConnectionInfo.cpp:111 0x0804fd02 11 apache::activemq::client::protocol::OpenWireFormat::marshal() at src/protocol/OpenWireFormat.cpp:89 0x0808c0a3 10 apache::activemq::client::transport::SocketTransport::send() at src/transport/SocketTransport.cpp:144 0x08051650 9 apache::activemq::client::transport::SocketTransport::asyncRequest() at src/transport/SocketTransport.cpp:109 0x08052e11 8 apache::activemq::client::transport::SocketTransport::request() at src/transport/SocketTransport.cpp:123 0x08051362 7 apache::activemq::client::Connection::syncRequest() at src/Connection.cpp:188 0x0805e31e 6 apache::activemq::client::Connection::checkConnected() at src/Connection.cpp:298 0x0805e196 5 apache::activemq::client::Connection::syncRequest() at src/Connection.cpp:186 0x0805e2d1 4 apache::activemq::client::Connection::createSession() at src/Connection.cpp:173 0x0805fb56 3 apache::activemq::client::Connection::createSession() at src/Connection.cpp:162 0x0805db3b 2 Tester::test() at ../main.cpp:47 0x0804bd8a 1 main() at ../main.cpp:102 0x0804ab34 My code is a modified version of the cms sample ... the guts of the code is shown below int numMessages =
RE: [jira] Updated: (AMQ-656) Update of AMQ C++ client
Oops... I've been building it using GCC on a linux but where the path is smbmount:ed and hosted by a windows machine. Sorry about the error. Thanks, /David -Original Message- From: Nathan Mittler [mailto:[EMAIL PROTECTED] Sent: den 26 mars 2006 19:51 To: activemq-dev@geronimo.apache.org Subject: Re: [jira] Updated: (AMQ-656) Update of AMQ C++ client Hi David, One minor tweak (for linux) ... in Guid.cpp, the include should be Guid.hpp, not guid.hpp. Paths in linux are case-sensitive, so it won't build. Regards, Nate On 3/24/06, David Fahlander (JIRA) [EMAIL PROTECTED] wrote: [ http://jira.activemq.org/jira//browse/AMQ-656?page=all ] David Fahlander updated AMQ-656: Attachment: source_060324.zip This is a complete update that replaces the previous attached file. Now compiles without warnings with full warning turned on on the following compilers: gcc 3.4.3 gcc 4.0.2 visual c++ 2005 Fixes also done with marshalling of messageId as int instead of short. Update of AMQ C++ client Key: AMQ-656 URL: http://jira.activemq.org/jira//browse/AMQ-656 Project: ActiveMQ Type: Improvement Components: JMS client Reporter: MF Attachments: source_060323.zip, source_060324.zip Attached is a new update of the C++ client, the zip-file contains the full source since the update is a major overhaul. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-656) Update of AMQ C++ client
[ http://jira.activemq.org/jira//browse/AMQ-656?page=all ] David Fahlander updated AMQ-656: Attachment: source_060324.zip This is a complete update that replaces the previous attached file. Now compiles without warnings with full warning turned on on the following compilers: gcc 3.4.3 gcc 4.0.2 visual c++ 2005 Fixes also done with marshalling of messageId as int instead of short. Update of AMQ C++ client Key: AMQ-656 URL: http://jira.activemq.org/jira//browse/AMQ-656 Project: ActiveMQ Type: Improvement Components: JMS client Reporter: MF Attachments: source_060323.zip, source_060324.zip Attached is a new update of the C++ client, the zip-file contains the full source since the update is a major overhaul. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: AMQ C#/C++ client refactoring suggestion
F.Y.I I'm currently merging Nathan's patch with what Mats and I have been doing. If anyone is doing a lot of coding based on the checked in openwire-cpp, please let us know. None of us has contributorship right now so we have to do a little manual merging... When the merge is finished, I'll post it to Jira in hope of getting it checked in. David -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: den 8 mars 2006 17:59 To: activemq-dev@geronimo.apache.org Subject: 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
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
