[
https://issues.apache.org/jira/browse/QPID-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated QPID-1843:
---------------------------
Attachment: (was: embedded-agent.diff)
> Multiple use of single qpid::management::ManagementAgent::Singleton confusing
> and error-prone
> ---------------------------------------------------------------------------------------------
>
> Key: QPID-1843
> URL: https://issues.apache.org/jira/browse/QPID-1843
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker, Qpid Managment Framework
> Affects Versions: 0.5
> Reporter: Steve Huston
> Assignee: Ted Ross
>
> Currently the qpid/agent/ManagementAgent.h file declares the
> qpid::management::ManagementAgent pure virtual class. Places where management
> agent functionality is desired must derive a class from ManagementAgent at a
> minimum. This is fine. However, there's also a non-virtual
> ManagementAgent::Singleton class defined in ManagementAgent.h. Current
> practice for this arrangement requires each place where a
> ManagementAgent-derived class is defined to also reimplement (including
> static class members) qpid::management::ManagementAgent::Singleton, the
> implementation of which manages the new class derived from ManagementAgent.
> This causes a problem because the ManagementAgent::Singleton class's member
> functions must be exported from the implementing DLL. However, the
> implementing DLL is not known when the class is declared and, in fact, there
> may be multiple implementations. For example, the qmf-agent has an
> implementation, and so does the broker. Currently, Singleton is marked as
> exported from the QMF-agent library. Thus, when broker is built, it sees both
> locally-defined and imported Singleton symbols. Apparantly, g++ is ok with
> this and just takes the local one (even if that's not what you want, but I
> digress...).
> It wouldn't work to just avoid exporting the symbols, because they are needed
> externally. For example, the acl plugin needs to get the broker's singleton
> pointer.
> One idea is to simply avoid the use of Singleton. If a instance of a
> ManagementAgent-derived class is desired, just instantiate one. Or add a
> method to the subclass to manage a singleton. Or whatever works for the
> particular class's use cases. The point is to push the lifetime management to
> the agent-derived class.
> In the case of the broker, the ManagementBroker (derived from
> ManagementAgent) could simply be used (or not, depending on the
> disable-management setting), and a method be added to Broker to obtain the
> ManagementAgent pointer, which could be a refcounted pointer since it's often
> saved. Then the, for example, ManagementBroker could export the symbols it
> needs, if any, in addition to the getMgmtAgent (or whatever) method.
> Any other ideas on this? I can start working on the changes when we decide on
> a way to go.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
