[
https://issues.apache.org/jira/browse/QPID-1843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated QPID-1843:
---------------------------
Attachment: embedded-agent.diff
This is a patch that removes the Singleton factory in ManagementBroker and
should solve the import-export issue being seen in windows.
This patch effectively separates the qmf agent library completely from the
embedded qmf agent in the broker.
One key attribute of this patch is that it does not change the qmf agent API
used externally from the broker. It does change the API for broker plugins.
I've attached it here for review. I will commit at a later time if there are
no issues found with it.
-Ted
> 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
> Attachments: embedded-agent.diff
>
>
> 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]
