RE: Openwire C Client.
Hi Vik, Is this the latest? Dated April 13th..? Is it declared release candidate yet? http://people.apache.org/~chirino/incubator-activemq-4.0-RC3/distributions/ I read a post by you on the forum with a pending issue with AMQ-RC3 and the consumer hanging if there is more than one message on the queue. Is that something I need to be concerned about. Please advise. Thanks very much, - Sunil -- View this message in context: http://www.nabble.com/Openwire-C-Client.-t1506711.html#a4127417 Sent from the ActiveMQ - Dev forum at Nabble.com.
Openwire C client issue
Hi, When i am trying to build Openwire C client i am getting following errors in ow_commands_v1.c. CC -mt -D_REENTRANT -DNO_SSL -DSAPI_LINUX -DOS_LINUX_2_2 -DEFX -DLINUX -D_GNU_SOURCE -DADDR_SRV -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64 -DHTREE -I../libactivemq -I../libopenwire -I/usr/local/apr/include/apr-1 -L/usr/local/apr/lib-c -o ow_commands_v1.o ../libopenwire/ow_commands_v1.c ../libopenwire/ow_commands_v1.c, line 416: Error: OW_FLUSHCOMMAND_TYPE is not defined. ../libopenwire/ow_commands_v1.c, line 416: Error: An integer constant expression is required for a case label. ../libopenwire/ow_commands_v1.c, line 1580: Error: OW_FLUSHCOMMAND_TYPE is not defined. ../libopenwire/ow_commands_v1.c, line 1580: Error: An integer constant expression is required for a case label. ../libopenwire/ow_commands_v1.c, line 1591: Error: OW_FLUSHCOMMAND_TYPE is not defined. ../libopenwire/ow_commands_v1.c, line 2533: Error: OW_FLUSHCOMMAND_TYPE is not defined. ../libopenwire/ow_commands_v1.c, line 2533: Error: An integer constant expression is required for a case label. ../libopenwire/ow_commands_v1.c, line 2533: Error: Case label defined twice. ../libopenwire/ow_commands_v1.c, line 2586: Error: OW_FLUSHCOMMAND_TYPE is not defined. ../libopenwire/ow_commands_v1.c, line 2586: Error: An integer constant expression is required for a case label. ../libopenwire/ow_commands_v1.c, line 2586: Error: Case label defined twice. ../libopenwire/ow_commands_v1.c, line 2639: Error: OW_FLUSHCOMMAND_TYPE is not defined. ../libopenwire/ow_commands_v1.c, line 2639: Error: An integer constant expression is required for a case label. ../libopenwire/ow_commands_v1.c, line 2639: Error: Case label defined twice. ../libopenwire/ow_commands_v1.c, line 2692: Error: OW_FLUSHCOMMAND_TYPE is not defined. ../libopenwire/ow_commands_v1.c, line 2692: Error: An integer constant expression is required for a case label. ../libopenwire/ow_commands_v1.c, line 2692: Error: Case label defined twice. Any insight Thanks! -- View this message in context: http://www.nabble.com/Openwire-C-client-issue-t1436230.html#a3875953 Sent from the ActiveMQ - Dev forum at Nabble.com.
RE: Regarding feedback on OpenWire C++ client
Hi Hiram, 5) .NET namespace Hiram, what rules does Apache imply on this? Is it ok to use the namespaces your giving examples on? Looking on the Java code all Apache code starts with org.apache. As far as I know the org.apache namespace is a Java thing as it's the only language the encourages that form. I've never seen this form use in other languages yet. Even so it might be better to be a bit overzealous to prevent namespace clashes :) If ASF does not have any rules about this we'll change it - no problem. However, if we're to sync the names between C# and C++ the C# name spaces should be altered also!? C# namespace cms namespace activemq.command namespace activemq.core namespace activemq.io C++ namespace cms namespace activemq::command namespace activemq::io namespace activemq::marshal namespace activemq::protocol namespace activemq::transport namespace activemq::util Regards, Mats
Re: Regarding feedback on OpenWire C++ client
On 3/28/06, David Fahlander [EMAIL PROTECTED] wrote:
Hi Nathan,
1) Use of smart pointers.
Though the user interface would be cleaner without smart pointers
they
serves a purpose even when the passed in object is not owned by the
client.
As soon as an object is shared between two classes you have the
problem when the object should be deleted - this problem is
eliminated
when using SP's, the object is deleted when both object releases its
reference to it.
I'm not sure I agree. For user-generated objects, it should be up to
the user to
add and remove references to them across the openwire library (such as
references
to IMessageListeners). When the user passes in a reference to one of
his objects,
he's not expecting to give any amount of lifetime control to the
openwire code.
In fact, the user object may not even have been created on the heap,
it may be a
local variable that was added just for the scope of a function. In
this case,
when the openwire library decides to delete it, the application blows
up! We
have to make a separation of what is and what is not under our
library's control.
We can't assume a structure of the client code, this forces the client
into a
particular way of programming and causes our client to become a burden
to the
developer and will turn them off to using ActiveMQ.
Regarding objects that the user provides, we still get benefits by using
smart pointers for them. It is not always the creator that is
responsible of deletion. Especially in a threaded application it can be
important to not end-up with ghost pointers. A thread in our client
library that holds a pointer to a listener, must be able to rely on that
the instance is still alive as long as it holds the SP to it. If the
user would provide an ordinary pointer, the user must never delete it as
long as there might be threads in our library using it. What about
static objects that should last forever in the client's lifetime then?
Still, we want to be able to take down the client in a controlled way.
Doing that without smart pointers, may create a lot of problems in our
experience.
The burden for the user would only lie in the classes that implement
our interfaces. If our API requires a pIMessageListener, the user must
hold his message listener using a pMyMessageListener allocated with
new MyMessageLister (...);. The user does not have to let this affect
his design. If the user wants, this instance can lie as a member within
another class that is neither derived from our interface nor maintained
as a smart pointer.
You get no benefits at all by adding smart pointers to the interface. The
user will delete their objects whenever they wish, regardless of what the
openwire library does ... and if it does so, the openwire library will
explode as soon as it tries to reference it. That's the thing - this is C++
and there is no mechanism to prevent someone from coding badly, and adding
smart pointers to the API isn't going to change that. The user is
responsible for both adding and removing referenes to its objects. And it's
not the job of the openwire lib to worry about memory management in the
user-domain - it should only be concerned with its own memory management.
In addition, smart pointers are assuming that the object is allocated on the
heap, as it will do a delete when the last reference is removed. This is
wrong, because the user should be able allocate its objects in whatever way
makes sense for the application.
Also, adding smart pointer arguments to all the methods on the api makes it
complicated and ugly. If the openwire library wants to use smart pointers
internally, that's fine, but it shouldn't impose the use of smart pointers
on the user. It's our job to make the user's experience a good one so they
continue to use ActiveMQ in their applications.
SP's and Strings: Semi-agreed :) The setters should all have const
char*
but we could change the getters to std:string (without SP), then it
is
up to the user to either use it as a std:string or a const char*.
I think symmetry is a good thing. We should pick one way or the other
...
either both the getter and setter take const char* or they both take
strings.
Also, when passing strings around, they should be passed as const
std::string ...
this way you don't have to copy the entire string, you just pass a
constant reference
to it. This will save a lot of processing when dealing with large
text messages, for
example.
The options we have regarding passing and holding strings are the
following:
Class Xxx {
pstring name;
public:
void setName (pstring name) {
this-name = name;
}
pstring getName () {
return this-name;
}
pstring createName() {
return new string (name: + *name);
}
};
In the above example, strings are never copied, just the ptr value. The
downside is that the caller needs to pass their strings as
RE: Regarding feedback on OpenWire C++ client
Nate,
You get no benefits at all by adding smart pointers to the interface.
The user will delete their objects whenever they wish, regardless of
what the openwire library does ... and if it does so, the openwire
library will explode as soon as it tries to reference it. That's the
thing - this is C++ and there is no mechanism to prevent someone from
coding badly, and adding smart pointers to the API isn't going to change
that. The user is responsible for both adding and removing referenes to
its objects. And it's not the job of the openwire lib to worry about
memory management in the user-domain - it should only be concerned with
its own memory management.
In addition, smart pointers are assuming that the object is allocated on
the heap, as it will do a delete when the last reference is removed.
This is wrong, because the user should be able allocate its objects in
whatever way makes sense for the application.
Also, adding smart pointer arguments to all the methods on the api makes
it complicated and ugly. If the openwire library wants to use smart pointers
internally, that's fine, but it shouldn't impose the use of smart pointers
on the user. It's our job to make the user's experience a good one so they
continue to use ActiveMQ in their applications.
Please define the interfaces that you want to be SP-free!
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.
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
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: Regarding feedback on OpenWire C++ client
On 3/28/06, Mats Forslöf [EMAIL PROTECTED] wrote: Hi Hiram, Even so it might be better to be a bit overzealous to prevent namespace clashes :) I would like to make this c++ lib, feel very c++ like, I don't want it to smell like it came from a Java shop. So I think it's better to have short names like most of the other libs out there. If ASF does not have any rules about this we'll change it - no problem. However, if we're to sync the names between C# and C++ the C# name spaces should be altered also!? C# namespace cms namespace activemq.command namespace activemq.core namespace activemq.io No.. becaue the C# one alos works for VB.NET and J# etc. etc. that's why the interface are in the .NET Message Service (NMS) namespace. Also .Net uses Camel case convention in it's namespaces. So we will do it like that. Once again the aim is to have a .NET library the feels very native. C++ namespace cms namespace activemq::command namespace activemq::io namespace activemq::marshal namespace activemq::protocol namespace activemq::transport namespace activemq::util This looks good to me! Regards, Mats -- Regards, Hiram
Regarding feedback on OpenWire C++ client
Hi All, Thanks everyone for looking at and testing the latest C++ client update. Sorry if we have not been so clear regarding the stability of the code, the code is highly untested and as said in the upload mail we will commence testing/debugging shortly - so expect bugs!! As we've just finished the port we will shift focus and look into all the issues you have raised, see comments below. 1) Use of smart pointers. Though the user interface would be cleaner without smart pointers they serves a purpose even when the passed in object is not owned by the client. As soon as an object is shared between two classes you have the problem when the object should be deleted - this problem is eliminated when using SP's, the object is deleted when both object releases its reference to it. SP's and Strings: Semi-agreed :) The setters should all have const char* but we could change the getters to std:string (without SP), then it is up to the user to either use it as a std:string or a const char*. 2) ITextMessage should extend IMessage This was a last minute change to make it compile. Nate, your solution seems to be a viable way of handling it - thanks! 3) SP dynamic_cast rather than reinterpret_cast It is correct that reinterpret_cast does not adjust the pointer value as needed when casting between different classes in a class hierarchy. However, the reinterpret_cast is used for casting between void* and objects and is needed for the p template to work. Where such pointer-value-adjustment is needed (up/down-casting), static_cast is used which works the same as dynamic_cast except that it does no runtime type check. 4) ExceptionListener An ExceptionListener is missing. We could either add a method on IMessageListener or add a new interface IExceptionListener, prefer the latter. Ok? 5) .NET namespace Hiram, what rules does Apache imply on this? Is it ok to use the namespaces your giving examples on? Looking on the Java code all Apache code starts with org.apache. Regards, Mats David
Re: Regarding feedback on OpenWire C++ client
Hi Mats, On 3/27/06, Mats Forslöf [EMAIL PROTECTED] wrote: Hi All, Thanks everyone for looking at and testing the latest C++ client update. Sorry if we have not been so clear regarding the stability of the code, the code is highly untested and as said in the upload mail we will commence testing/debugging shortly - so expect bugs!! No problem, bugs are expected ... just reporting that I think I found one :-) As we've just finished the port we will shift focus and look into all the issues you have raised, see comments below. 1) Use of smart pointers. Though the user interface would be cleaner without smart pointers they serves a purpose even when the passed in object is not owned by the client. As soon as an object is shared between two classes you have the problem when the object should be deleted - this problem is eliminated when using SP's, the object is deleted when both object releases its reference to it. I'm not sure I agree. For user-generated objects, it should be up to the user to add and remove references to them across the openwire library (such as references to IMessageListeners). When the user passes in a reference to one of his objects, he's not expecting to give any amount of lifetime control to the openwire code. In fact, the user object may not even have been created on the heap, it may be a local variable that was added just for the scope of a function. In this case, when the openwire library decides to delete it, the application blows up! We have to make a separation of what is and what is not under our library's control. We can't assume a structure of the client code, this forces the client into a particular way of programming and causes our client to become a burden to the developer and will turn them off to using ActiveMQ. SP's and Strings: Semi-agreed :) The setters should all have const char* but we could change the getters to std:string (without SP), then it is up to the user to either use it as a std:string or a const char*. I think symmetry is a good thing. We should pick one way or the other ... either both the getter and setter take const char* or they both take strings. Also, when passing strings around, they should be passed as const std::string ... this way you don't have to copy the entire string, you just pass a constant reference to it. This will save a lot of processing when dealing with large text messages, for example. 2) ITextMessage should extend IMessage This was a last minute change to make it compile. Nate, your solution seems to be a viable way of handling it - thanks! No problem. 3) SP dynamic_cast rather than reinterpret_cast It is correct that reinterpret_cast does not adjust the pointer value as needed when casting between different classes in a class hierarchy. However, the reinterpret_cast is used for casting between void* and objects and is needed for the p template to work. Where such pointer-value-adjustment is needed (up/down-casting), static_cast is used which works the same as dynamic_cast except that it does no runtime type check. Hmmm ... so why are we using void* instead of T*? 4) ExceptionListener An ExceptionListener is missing. We could either add a method on IMessageListener or add a new interface IExceptionListener, prefer the latter. Ok? Agreed. 5) .NET namespace Hiram, what rules does Apache imply on this? Is it ok to use the namespaces your giving examples on? Looking on the Java code all Apache code starts with org.apache. Regards, Mats David Regards, Nate
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: Regarding feedback on OpenWire C++ client
On 3/27/06, Mats Forslöf [EMAIL PROTECTED] wrote: 5) .NET namespace Hiram, what rules does Apache imply on this? Is it ok to use the namespaces your giving examples on? Looking on the Java code all Apache code starts with org.apache. As far as I know the org.apache namespace is a Java thing as it's the only language the encourages that form. I've never seen this form use in other languages yet. Regards, Mats David -- Regards, Hiram
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 = 1000;
int sleepTime = 10;
printf(Starting activemqcms test (sending %d messages and
sleeping %d seconds) ...\n, numMessages, sleepTime );
// START SNIPPET: demo
ConnectionFactory connectionFactory( pUri(new
Uri(tcp://127.0.0.1:61616) ) );
pIConnection connection = connectionFactory.createConnection
();
pISession session = connection-createSession();
pITopic topic = session-getTopic(mytopic);
pMessageConsumer consumer =
p_castMessageConsumer(session-createConsumer( topic ));
consumer-setMessageListener( pIMessageListener(this) );
pIMessageProducer producer = session-createProducer( topic );
const char* text = this is a test!;
pITextMessage msg = session-createTextMessage( text );
for( int ix=0; ixnumMessages; ++ix ){
producer-send( msg );
doSleep
Re: openwire C++ client
Hi Nathan, On 3/26/06, Nathan Mittler [EMAIL PROTECTED] wrote: 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. I agreed. I think it may be possible to be even more aggressive and avoid having the interface classes use smart pointers at all. I think the if we define good ownership rules, then we do not need to have the API user need to worry about smart pointers. On a related note, It would be nice if the name spaces used were changed so that they paralleled the .NET stuff a little closer. It might be nice to have a 'cms' name space the holds all the interface classes and a 'activemq', 'activemq::transport', etc. name space that holds all the activemq implementation of the interfaces. Using 'org::apache::activemq' seems a little verbose to me. Regards, Hiram 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. agreed. 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. The joys of multiple inheritance :) -- Regards, Hiram
RE: Trouble uploading OpenWire C++ client to mailing list
Thanks Hiram! The source is uploaded onto issue Geronimo-1623. The code is split into two files, one for the C++ client and one for Davids source that should be pulled from his site on a build. Please let me know how we should proceed, we need help from James or someone to get the auto generation of the commands going. Regards, Mats -Original Message- From: Hiram Chirino [mailto:[EMAIL PROTECTED] Sent: den 10 februari 2006 17:01 To: activemq-dev@geronimo.apache.org Subject: Re: Trouble uploading OpenWire C++ client to mailing list Hi Mats, As a work around, Try putting it in the geronimo JIRA here: http://issues.apache.org/ jira/secure/BrowseProject.jspa?id=10220 Assign it to the ActiveMQ component and we should be able to find it. Regards, Hiram On Feb 10, 2006, at 6:20 AM, Mats Forslöf wrote: Hi Rob, The patch is not more than 10k in compressed form. I tried to upload it to Jira again but with the same proxy problem. Mats -Original Message- From: Rob Davies [mailto:[EMAIL PROTECTED] Sent: den 10 februari 2006 11:40 To: activemq-dev@geronimo.apache.org Subject: Re: Trouble uploading OpenWire C++ client to mailing list There's been some problems today with jira - but seems to be working ok now. Attaching the file to jira seems the best thing todo - how big is the patch ? cheers, Rob On 10 Feb 2006, at 08:44, Mats Forslöf wrote: Great, adding it to Jira doesn't work either, got a proxy error, see below. Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /jira/secure/ CreateIssueDetails.jspa. Reason: Error reading from remote server - - -- Apache/2.0.52 (Fedora) Server at jira.activemq.org Port 80 Any ideas on how to upload the patch? Regards, Mats -Original Message- From: Mats Forslöf [mailto:[EMAIL PROTECTED] Sent: den 10 februari 2006 09:18 To: activemq-dev@geronimo.apache.org Subject: Trouble uploading OpenWire C++ client to mailing list Hi, I've been tryint to send patches to this mailing list but it doesn't seem to work. Should I put in a Jira isssue instead? Regards, Mats
Re: Trouble uploading OpenWire C++ client to mailing list
Hi Mats, I just finished committing the patch. I put it under activemq/ openwire-cpp. I uploaded the smart pointer header dependencies that the code has up to http://www.codehaus.org/~chirino/util/ifr/v1 It should be possible to cook up a build script the does a wget of the .hpp files automatically so that folks don't need to manually download. Regards, Hiram On Feb 13, 2006, at 12:33 PM, Hiram Chirino wrote: Good point.. Since it s port of the c# stuff I guess it's quite different than brand new stuff. I'll get it checked in today. Regards, Hiram On Feb 13, 2006, at 10:26 AM, Mats Forslöf wrote: Is that really necessary in this case?? The code is a port of your C# client so the code is _very_ similar, shouldn't be any problem with IP there. :-) Regards, Mats -Original Message- From: Hiram Chirino [mailto:[EMAIL PROTECTED] Sent: den 13 februari 2006 16:11 To: activemq-dev@geronimo.apache.org Subject: Re: Trouble uploading OpenWire C++ client to mailing list Hi Matts! Awesome work! There's just so much of it! Usually it's no problem to accept a small patch, but with larger patches Apache likes to get a Contributor License Agreement (CLA) to make sure the IP is clear. If you get a chance, could you fill out and fax in the following form??? http://www.apache.org/licenses/icla.pdf Thanks, Hiram On Feb 13, 2006, at 3:50 AM, Mats Forslöf wrote: Thanks Hiram! The source is uploaded onto issue Geronimo-1623. The code is split into two files, one for the C++ client and one for Davids source that should be pulled from his site on a build. Please let me know how we should proceed, we need help from James or someone to get the auto generation of the commands going. Regards, Mats -Original Message- From: Hiram Chirino [mailto:[EMAIL PROTECTED] Sent: den 10 februari 2006 17:01 To: activemq-dev@geronimo.apache.org Subject: Re: Trouble uploading OpenWire C++ client to mailing list Hi Mats, As a work around, Try putting it in the geronimo JIRA here: http://issues.apache.org/ jira/secure/BrowseProject.jspa?id=10220 Assign it to the ActiveMQ component and we should be able to find it. Regards, Hiram On Feb 10, 2006, at 6:20 AM, Mats Forslöf wrote: Hi Rob, The patch is not more than 10k in compressed form. I tried to upload it to Jira again but with the same proxy problem. Mats -Original Message- From: Rob Davies [mailto:[EMAIL PROTECTED] Sent: den 10 februari 2006 11:40 To: activemq-dev@geronimo.apache.org Subject: Re: Trouble uploading OpenWire C++ client to mailing list There's been some problems today with jira - but seems to be working ok now. Attaching the file to jira seems the best thing todo - how big is the patch ? cheers, Rob On 10 Feb 2006, at 08:44, Mats Forslöf wrote: Great, adding it to Jira doesn't work either, got a proxy error, see below. Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /jira/secure/ CreateIssueDetails.jspa. Reason: Error reading from remote server -- -- - - -- Apache/2.0.52 (Fedora) Server at jira.activemq.org Port 80 Any ideas on how to upload the patch? Regards, Mats -Original Message- From: Mats Forslöf [mailto:[EMAIL PROTECTED] Sent: den 10 februari 2006 09:18 To: activemq-dev@geronimo.apache.org Subject: Trouble uploading OpenWire C++ client to mailing list Hi, I've been tryint to send patches to this mailing list but it doesn't seem to work. Should I put in a Jira isssue instead? Regards, Mats
RE: Trouble uploading OpenWire C++ client to mailing list
Great, adding it to Jira doesn't work either, got a proxy error, see below. Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /jira/secure/CreateIssueDetails.jspa. Reason: Error reading from remote server Apache/2.0.52 (Fedora) Server at jira.activemq.org Port 80 Any ideas on how to upload the patch? Regards, Mats -Original Message- From: Mats Forslöf [mailto:[EMAIL PROTECTED] Sent: den 10 februari 2006 09:18 To: activemq-dev@geronimo.apache.org Subject: Trouble uploading OpenWire C++ client to mailing list Hi, I've been tryint to send patches to this mailing list but it doesn't seem to work. Should I put in a Jira isssue instead? Regards, Mats
RE: Trouble uploading OpenWire C++ client to mailing list
Hi Rob, The patch is not more than 10k in compressed form. I tried to upload it to Jira again but with the same proxy problem. Mats -Original Message- From: Rob Davies [mailto:[EMAIL PROTECTED] Sent: den 10 februari 2006 11:40 To: activemq-dev@geronimo.apache.org Subject: Re: Trouble uploading OpenWire C++ client to mailing list There's been some problems today with jira - but seems to be working ok now. Attaching the file to jira seems the best thing todo - how big is the patch ? cheers, Rob On 10 Feb 2006, at 08:44, Mats Forslöf wrote: Great, adding it to Jira doesn't work either, got a proxy error, see below. Proxy Error The proxy server received an invalid response from an upstream server. The proxy server could not handle the request POST /jira/secure/ CreateIssueDetails.jspa. Reason: Error reading from remote server -- -- Apache/2.0.52 (Fedora) Server at jira.activemq.org Port 80 Any ideas on how to upload the patch? Regards, Mats -Original Message- From: Mats Forslöf [mailto:[EMAIL PROTECTED] Sent: den 10 februari 2006 09:18 To: activemq-dev@geronimo.apache.org Subject: Trouble uploading OpenWire C++ client to mailing list Hi, I've been tryint to send patches to this mailing list but it doesn't seem to work. Should I put in a Jira isssue instead? Regards, Mats
