Hi Arjun and Aleksander
The project has had no recent contributions as you can clearly see, this is due to lack of contributors/committers being active on it, after all things live or die by contributors actively contributing. As such if you were to want to actively contribute then I see nothing stopping you, then it would become active again, i know that others maybe thankful to you in-fact, especially those that are using ActiveMQ 5 and Openwire where the is no alternative, and need a cpp client thats at least compiles. Contributions can be done by raising JIRA's and then simply raising PR's attributed to those Jiras, and having a community review them, this maybe a bit tricky if you're a lone contributor/developer...as you wont have your PR approved or merged, but if there is a community of cpp/c people that actively work on this in the apache way, it seems by the fact there is two of you already collaborating in this email thread, it seems like there is some momentum. The one thing you will need to do is try get a current PMC or Committer on board who has some c/c++ background to perform your merges and to run a release for you only these people can do this, you can find list of people here, https://people.apache.org/phonebook.html?pmc=activemq, I know small maintenance bits have been done by Jamie Goodyear and Tim Bish so maybe some first names to try talk with. Best Mike On 16 December 2020 at 20:48, Arjun Ray <[email protected]> wrote: On Mon, 14 Dec 2020 16:38:12 +0100, Aleksander Miera wrote: | I started writing some RAII-related code for the library types/functions | (e.g. custom deleters), and it made me wonder: would it not be good | to provide some of those functionalities on library level? I think, probably not. In both interface and internals, the library shows clear signs of an effort to adopt Java styles and to copy Java idioms as slavishly as possible. Java doesn't have deleters, so adding them here would not be a good fit. The lack of them actually points to more fundamental issues. The library should have had a C rather than C++ interface. Tibco EMS is based on the JMS specification by design and intent, but wisely the interface is in C rather than C++. Solace, as another example, offers a client library in C but not in C++. Professional products eschewing a C++ interface is quite telling. The basic reason is strategies for resource management. Tibco and Solace offer opaque pointers and external functions (in C++ parlance); so you find both create_XXX() and destroy_XXX() calls in the API. Wrapping these in C++ classes is straightforward. More importantly, how these wrapper classes are instantiated - heap allocated or stack allocated - is left to the higher level C++ code, which is as it should be. To use the Activemq-cpp library sanely, we end up doing the same thing. A custom deleter would be only part of a more general approach to wrapping allocation and access. E.g. class ConnectionPtr { std::unique_ptr<activemq::core::ActiveMQConnection> ptr_; public: ~ConnectionPtr() noexcept(false) { try { ptr_->close(); } catch (cms::CMSException&) {} } explicit ConnectionPtr(std::string const& brokerURI) :ptr_(activemq::core::ActiveMQConnectionFactory(brokerURI).createConnection()) {} activemq::core::ActiveMQConnection* operator->() { return ptr_.get(); } }; Then, use a ConnectionPtr as an argument to the constructor of a SessionPtr defined along similar lines: class SessionPtr { std::unique_ptr<activemq::core::ActiveMQSession> ptr_; public: ~SessionPtr() noexcept(false) { try { ptr_->close(); } catch (cms::CMSException&) {} } explicit SessionPtr(ConnectionPtr& cp, cms::Session::AcknowledgeMode ackMode = cms::Session::AUTO_ACKNOWLEDGE) : ptr_(cp->createSession( ackMode )) {} cms::Session* operator->() { return ptr_.get(); } }; [SessionPtr can be used similarly for a ProducerPtr, and so on.] The Java-centric alternative of using explicit creational methods (in contrast to dependency injection into constructors, as above) creates needless difficulties, as you have to pre-commit to heap allocation, willy nilly. Instead, the idea should be to leave those creational methods to the C layer and build the C++ layer on top of that, with freedom to allocate on heap or stack as warranted. Note that this involves treating the Activemq-cpp class pointers like C layer opaque pointers as much as possible. | Last but not least, auto_ptr deprecation warnings look just ugly on | in my build log and maybe at least moving away from those should do | no harm. C++17 removed std::auto_ptr altogether: the codebase shouldn't even compile. Replacing std::auto_ptr with std::unique_ptr is relatively straightforward, as it happens. See, on this list, http://activemq.2283324.n4.nabble.com/Replacing-std-auto-ptr-in-ActiveMQ-CPP-v-3-9-5-tp4759225.html | If this is totally undesired and "backwards compatibility is king" | feel free to turn me down. I get the impression that the Activemq-cpp library is transitioning into maintenance mode. There doesn't seem to be much interest. -- :ar
