You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Andrew Stitcher (JIRA)" <qp...@incubator.apache.org> on 2009/11/30 16:59:21 UTC

[jira] Issue Comment Edited: (QPID-2223) Controlling order of plug-in initialization.

    [ https://issues.apache.org/jira/browse/QPID-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12783717#action_12783717 ] 

Andrew Stitcher edited comment on QPID-2223 at 11/30/09 3:59 PM:
-----------------------------------------------------------------

I don't like solutions that rely on an extrinsic numbering because it can be hard to figure out the correct value unless you know about absolutely every module that could be loaded.

I think that a better solution would be one which uses a dependency tree.

So I think it's more useful for plugins to specify which other plugins they depend on.

Then the module code initialises them in the correct order.

This definitely leads to more complication, as you have to deal with optional and required dependencies, but I think it "does the right thing" in an explicit way.

      was (Author: astitcher):
    I don't like solutions that rely on an extrinsic numbering because it can be hard to figure out the correct value unless you know about absolutely every module than could be loaded.

I think that a better solution would be one which uses a dependency tree.

So I think it's more useful for plugins to specify which other plugins they depend on.

Then the module code initialises them in the correct order.

This definitely leads to more complication, as you have to deal with optional and required dependencies, but I think it "does the right thing" in an explicit way.
  
> Controlling order of plug-in initialization.
> --------------------------------------------
>
>                 Key: QPID-2223
>                 URL: https://issues.apache.org/jira/browse/QPID-2223
>             Project: Qpid
>          Issue Type: Improvement
>          Components: C++ Broker
>    Affects Versions: 0.5
>            Reporter: Alan Conway
>            Assignee: Alan Conway
>
> The specific  use case for this is as follows:
> The cluster plug-in needs to know in earlyInitialize whether or not the broker has a store so it can correctly advertise itself as persistent/transient when joining the cluster.  
> The current solution is 
>      /**                                                                                   
>       * Initialization order. If a plugin does not override this, it                       
>       * returns DEFAULT_INIT_ORDER. Plugins that need to be initialized                    
>       * earlier/later than normal can override initOrder to return                         
>       * a lower/higher value than DEFAULT_INIT_ORDER.                                      
>       */
>      QPID_COMMON_EXTERN virtual int initOrder() const;
> The cluster plugin sets a higher initOrder so it will initialize after the store and can test whether broker.getStore()  is a null store.
> This feature was added without sufficient discussion. The goal of this JIRA is to determine if there's a better solution that would apply more generally. If so we'll implement that instead. 

-- 
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:dev-subscribe@qpid.apache.org