所有Avalon的組件都是在某處創(chuàng)建的。創(chuàng)建該組件的代碼就是該組件的容器。容器負(fù)責(zé)管理組件從構(gòu)造到析構(gòu)的生命周期。容器可以有一個靜態(tài)的"main"方法，讓它能從命令行調(diào)用，或者它也可以是另一個容器。在您設(shè)計容器時，請記得反向控制的模式。信息和方法調(diào)用將只從容器流向組件。

為了管理子組件，您需要在它們整個生命同期都保存對它們的引用。在容器和其它組件可以使用該子組件之前，它必須完成初始化。對我們的DocumentRepository來說，代碼看起來可能象下面的樣子：

class ContainerComponent implements Component, Initializable, Disposable
{
    DocumentRepository docs = new DatabaseDocumentRepository();
    GuardianComponent guard = new DocumentGuardianComponent();
    DefaultComponentManager manager = new DefaultComponentManager();

    public void initialize()
        throws Exception
    {
        Logger docLogger = new LogKitLogger( Hierarchy.defaultHierarchy()
                                             .getLoggerFor( "document" ) );

        this.docs.enableLogging( docLogger.childLogger( "repository" ) );
        this.guard.enableLogging( docLogger.childLogger( "security" ) );

        DefaultConfiguration pool = new DefaultConfiguration("dbpool");
        pool.setValue("main-pool");
        DefaultConfiguration conf = new DefaultConfiguration("");
        conf.addChild(pool);

        this.manager.addComponent( DocumentRepository.ROLE, this.docs );
        this.manager.addComponent( GuardianComponent.ROLE, this.guard );
        this.docs.compose( this.manager );
        this.guard.compose( this.manager );

        this.docs.configure(conf);

        this.guard.initialize();
        this.docs.initialize();
    }

    public void dispose()
    {
        this.docs.dispose();
        this.guard.dispose();
    }
}

        

為了簡潔，我把顯式地檢查從以上代碼中移去了。您可以看到手工地創(chuàng)建和管理組件是很細(xì)節(jié)化的工作。如果您忘記做了組件生命周期中的某一步，您就會發(fā)現(xiàn)bug。這也需要對您正在實(shí)例化的組件有一些深入的了解。另一種做法是給上面的ContainerComponent增加一些方法，來動態(tài)地處理組件的初始化。

開發(fā)者的本性是懶惰的，所以他們會花時間寫一個特別的ComponentManager 作為系統(tǒng)中所有組件的容器。通過這種方式，他們就不必深入地了解系統(tǒng)中所有組件的接口。這可能是個令人沮喪的任務(wù)。Avalon的開發(fā)者已經(jīng)創(chuàng)建了這樣一個怪獸。Avalon Excalibur的組件體系結(jié)構(gòu)中包括了一個ComponentManager，通過XML的配置文件來控制。

當(dāng)您把管理組件的責(zé)任交給Excalibur的ComponentManager時，存在一個折衷。您放棄了對CompomentManager中包含哪些組件的精細(xì)控制。但是，如果您的系統(tǒng)相當(dāng)大，您會發(fā)現(xiàn)手工控制是一項(xiàng)令人沮喪的工作。在這種情況下，出于對系統(tǒng)穩(wěn)定性的考慮，最好由一個地方集中式地管理系統(tǒng)中所有的組件。

既然可以與Excalibur的組件體系結(jié)構(gòu)有不同中層次的集成程度，我們將從最低層次開始。Excalibur有一組ComponentHandler對象，它們作為每類組件獨(dú)立的容器。它們管理您的組件的整個生命周期。讓我們引入生存方式（lifestyle）接口的概念。一個生存方式接口描述了系統(tǒng)是怎樣對待一個組件的。既然組件的生存方式對系統(tǒng)運(yùn)行會產(chǎn)生影響，我們就需要討論當(dāng)前的一些生存方式所暗含的意義：

• org.apache.avalon.framework.thread.SingleThreaded

  • 不是線程安全的或可重用的。

  • 如果沒有指定其它生存方式方式接口，系統(tǒng)就認(rèn)為是這個。

  • 在每次請求組件時，都會創(chuàng)建一個全新的實(shí)例。

  • 實(shí)例的創(chuàng)建和初始化被推遲到請求組件時進(jìn)行。

• org.apache.avalon.framework.thread.Threadsafe

  • 組件是完全可重入的，并符合所有的線程安全的原則。

  • 系統(tǒng)創(chuàng)建一個實(shí)例，所有Composable組件對它的訪問是共享的。

  • 實(shí)例的創(chuàng)建和初始化是在ComponentHandler創(chuàng)建時完成的。

• org.apache.avalon.excalibur.pool.Poolable

  • 不是線程安全的，但是是完全可重用的。

  • 創(chuàng)建一組實(shí)例放在池中，當(dāng)Composable組件請求時，系統(tǒng)提供一個可用的。

  • 實(shí)例的創(chuàng)建和初始化是在ComponentHandler創(chuàng)建時完成的。

ComponentHandler接口處理起來是很簡單的。你通過Java類、Configuration對象、ComponentManager對象、Context對象和RoleManager對象來初始化構(gòu)造方法。 如果您知道您的組件將不需要上述的某一項(xiàng)，您可以在它的位置上傳一個null。 在這之后，當(dāng)您需要對該組件的引用時，您就調(diào)用"get"方法。當(dāng)您用完之后，您調(diào)用"put"方法將組件歸還給ComponentHandler。 以下的代碼便于我們理解這一點(diǎn)。

class ContainerComponent implements Component, Initializable, Disposable
{
    ComponentHandler docs = null;
    ComponentHandler guard = null;
    DefaultComponentManager manager = new DefaultComponentManager();

    public void initialize()
        throws Exception
    {
        DefaultConfiguration pool = new DefaultConfiguration("dbpool");
        pool.setValue("main-pool");
        DefaultConfiguration conf = new DefaultConfiguration("");
        conf.addChild(pool);
        this.docs.configure(conf);

        this.docs = ComponentHandler.getComponentHandler(
                                        DatabaseDocumentRepository.class,
                                        conf, this.manager, null, null);
        this.guard = ComponentHandler.getComponentHandler(
                                        DocumentGuardianComponent.class,
                                        null, this.manager, null, null);

        Logger docLogger = new LogKitLogger( Hierarchy.defaultHierarchy()
                                             .getLoggerFor( "document" ) );

        this.docs.enableLogging( docLogger.childLogger( "repository" ) );
        this.guard.enableLogging( docLogger.childLogger( "security" ) );

        this.manager.addComponent(DocumentRepository.ROLE, this.docs);
        this.manager.addComponent(GuardianComponent.ROLE, this.guard);

        this.guard.initialize();
        this.docs.initialize();
    }

    public void dispose()
    {
        this.docs.dispose();
        this.guard.dispose();
    }
}

        

這里，我們只少寫了幾行代碼。我們還是手工地創(chuàng)建了Configuration對象，還是設(shè)置了Logger，還是不得不對ComponentHandler對象進(jìn)行初始化和銷毀。 這里我們所做的只是防止受到接口變化的影響。您會發(fā)現(xiàn)用這種方式對代碼有好處。Excalibur所做的更進(jìn)了一步。大多數(shù)復(fù)雜的系統(tǒng)都有一些配置文件。它們允許管理員調(diào)整關(guān)鍵的配置信息。 Excalibur可以用以下的格式讀取配置文件，并從中創(chuàng)建系統(tǒng)的組件。

<my-system>
  <component
    role="org.apache.avalon.excalibur.datasource.DataSourceComponentSelector"
    class="org.apache.avalon.excalibur.component.ExcaliburComponentSelector">
     <component-instance name="documents"
       class="org.apache.avalon.excalibur.datasource.JdbcDataSource">
         <pool-controller min="5" max="10"/>
         <auto-commit>false</auto-commit>
         <driver>org.gjt.mm.mysql.Driver</driver>
         <dburl>jdbc:mysql:localhost/mydb</dburl>
         <user>test</user>
         <password>test</password>
      </component-instance>
      <component-instance name="security"
        class="org.apache.avalon.excalibur.datasource.JdbcDataSource">
         <pool-controller min="5" max="10"/>
         <auto-commit>false</auto-commit>
         <driver>org.gjt.mm.mysql.Driver</driver>
         <dburl>jdbc:mysql:localhost/myotherdb</dburl>
         <user>test</user>
         <password>test</password>
      </component-instance>
  </component>
  <component
    role="org.apache.bizserver.docs.DocumentRepository"
    class="org.apache.bizserver.docs.DatabaseDocumentRepository">
      <dbpool>documents</dbpool>
  </component>
  <component
    role="org.apache.bizserver.docs.GuardianComponent"
    class="org.apache.bizserver.docs.DocumentGuardianComponent">
      <dbpool>security</dbpool>
      <policy file="/home/system/document.policy"/>
  </component>
</my-system>

        

根元素可以由您任意指定。 您會注意到我們已經(jīng)定義了一些組件。 我們有了熟悉的DocumentRepository類和GuardianComponent類，以及一些Excalibur DataSourceComponent類。 而且，現(xiàn)在我們對Guardian組件有了一些特定的配置信息。 為了把這些系統(tǒng)讀入您的系統(tǒng)，Avalon框架為您提供了一些方便：

DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder();
Configuration systemConf = builder.buildFromFile("/path/to/file.xconf");

        

這確實(shí)對我們前面手工構(gòu)建配置元素的代碼起到了簡化作用，而且它限制了我們在編程時需要明確了解的信息。 讓我們再看一眼Container類，看看是否真的省了一些事。記住我們指定了5個組件( ComponentSelector算作是一個組件)， 以及每個組件的配置信息。

class ContainerComponent implements Component, Initializable, Disposable {
    ExcaliburComponentManager manager = new ExcaliburComponentManager();

    public void initialize()
        throws Exception
    {
        DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder();
        Configuration sysConfig = builder.buildFromFile("./conf/system.xconf");

        this.manager.setLogger(  Hierarchy.getDefaultHierarchy()
                                          .getLoggerFor("document") );
        this.manager.contextualize( new DefaultContext() );
        this.manager.configure( sysConfig );
        this.manager.initialize();
    }

    public void dispose()
    {
        this.manager.dispose();
    }
}

        

難道不令人驚奇？我們對數(shù)量超過兩倍的組件進(jìn)行了初始化，而代碼量減少了一倍多(6行代碼，而不是13行)。 這個配置文件有一個缺點(diǎn)，看起來有點(diǎn)瘋狂，但它將需要寫的代碼數(shù)量降到了最低。

在ExcaliburComponentManager的背后發(fā)生了很多的活動。 對配置文件中的每個"component"元素，Excalibur為每個類的條目（entry）創(chuàng)建了一個ComponentHandler，并建立起與角色（role）的對應(yīng)關(guān)系。 "component"元素和它的所有子元素是對組件的配置。當(dāng)組件是一個ExcaliburComponentSelector時， Excalibur會讀入每個"component-instance"元素并執(zhí)行和前面同類型的操作，這次是與hint entry建立對應(yīng)關(guān)系。

interface RoleManager
{
    String getRoleForName( String shorthandName );
    String getDefaultClassNameForRole( String role );
    String getDefaultClassNameForHint( String hint, String shorthand );
}

          

<role-list>
  <role
    name="org.apache.avalon.excalibur.datasource.DataSourceComponentSelector"
    shorthand="datasources"
    default-class="org.apache.avalon.excalibur.component.ExcaliburComponentSelector">
     <hint shorthand="jdbc"
       class="org.apache.avalon.excalibur.datasource.JdbcDataSourceComponent"/>
     <hint shorthand="j2ee"
       class="org.apache.avalon.excalibur.datasource.J2eeDataSourceComponent"/>
  </role>
  <role
    name="org.apache.bizserver.docs.DocumentRepository"
    shorthand="repository"
    default-class="org.apache.bizserver.docs.DatabaseDocumentRepository"/>
  <role
    name="org.apache.bizserver.docs.GuardianComponent"
    shorthand="guardian"
    default-class="org.apache.bizserver.docs.DocumentGuardianComponent"/>
</role-list>

          

DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder();
Configuration sysConfig = builder.buildFromFile("./conf/system.xconf");
Configuration roleConfig = builder.build(
            this.getClass().getClassLoader()
            .getResourceAsStream("/org/apache/bizserver/docs/document.roles"));

DefaultRoleManager roles = new DefaultRoleManager();
roles.enableLogging(Hierarchy.getDefaultHierarchy().getLoggerFor("document.roles"));
roles.configure(roleConfig);

this.manager.setLogger( Hierarchy.getDefaultHierarchy()
                           .getLoggerFor("document") );
this.manager.contextualize( new DefaultContext() );
this.manager.setRoleManager( roles );
this.manager.configure( sysConfig );
this.manager.initialize();

          

<my-system>
  <datasources>
     <jdbc name="documents">
         <pool-controller min="5" max="10"/>
         <auto-commit>false</auto-commit>
         <driver>org.gjt.mm.mysql.Driver</driver>
         <dburl>jdbc:mysql:localhost/mydb</dburl>
         <user>test</user>
         <password>test</password>
      </jdbc>
      <jdbc name="security">
         <pool-controller min="5" max="10"/>
         <auto-commit>false</auto-commit>
         <driver>org.gjt.mm.mysql.Driver</driver>
         <dburl>jdbc:mysql:localhost/myotherdb</dburl>
         <user>test</user>
         <password>test</password>
      </jdbc>
  </datasources>
  <repository>
      <dbpool>documents</dbpool>
  </repository>
  <guardian>
      <dbpool>security</dbpool>
      <policy file="/home/system/document.policy"/>
  </guardian>
</my-system>

          

class MyClass implements Component, Composable, Disposable
{
    ComponentManager manager;
    Guardian myGuard;

    /**
     * Obtain a reference to a guard and keep the reference to
     * the ComponentManager.
     */
    public void compose(ComponentManager manager)
        throws ComponentException
    {
        if (this.manager == null)
        {
            this.manager = manager;
            myGuard = (Guardian) this.manager.lookup(Guardian.ROLE);
        }
    }

    /**
     * This is the method that uses the Guardian.
     */
    public void myMethod()
        throws SecurityException
    {
        this.myGuard.checkPermission(new BasicPermission("test"));
    }

    /**
     * Get rid of our references
     */
    public void dispose()
    {
        this.manager.release(this.myGuard);
        this.myGuard = null;
        this.manager = null;
    }
}

        

從示例代碼中您可以看到，照這樣做很容易。當(dāng)該對象第一次接收到ComponentManager時，它取得了一個Guardian組件的引用。 如果您可以保證Guardian組件是線程安全的（實(shí)現(xiàn)了ThreadSafe接口），那么就只需要做這些事。 不幸的是，從長遠(yuǎn)來看，您不能保證這一點(diǎn)。為了能正確地管理資源，在用完組件之后，我們必須釋放對組件的引用。 這就是為什么我們保持一個對ComponentManager的引用的原因。

這種方式的主要不利之處在于處理組件池中的組件時。對組件的引用維系著該組件的生命。 如果該對象的生存期很短，這可能不是個問題；但是如果該對象是一個由Excalibur組件管理體系結(jié)構(gòu)所管理的組件，只要有對它的引用，它的生存期就會繼續(xù)。這意味著我們實(shí)際上把組件池變成了一個組件工廠。

這種方式的主要好處是，得到和釋放組件的代碼很清楚。 您不必去理解異常處理的代碼。

另一個細(xì)微差別是，您把Guardian的存在與初始化這個對象的能力捆綁在了一起。 一旦在一個對象的初始化階段拋出一個異常， 你就只好認(rèn)為該對象不是一個有效的對象。有時您希望當(dāng)要求的組件不存在時就讓程序失敗掉，那么這就不是問題。 在設(shè)計組件時，您確實(shí)需要注意到這一層隱含的意思。

class MyClass implements Composable, Disposable
{
    ComponentManager manager;

    /**
     * Obtain a reference to a guard and keep the reference to
     * the ComponentManager.
     */
    public void compose(ComponentManager manager)
        throws ComponentException
    {
        if (this.manager == null)
        {
            this.manager = manager;
        }
    }

    /**
     * This is the method that gets the Guardian.
     */
    public void myMethod()
        throws SecurityException
    {
        Guardian myGuard = null;
        try
        {
            myGuard = (Guardian) this.manager.lookup(Guardian.ROLE);
            this.criticalSection(myGuard);
        }
        catch (ComponentException ce)
        {
            throw new SecurityException(ce.getMessage());
        }
        catch (SecurityException se)
        {
            throw se;
        }
        finally
        {
            if (myGuard != null)
            {
                this.manager.release(myGuard);
            }
        }
    }

    /**
     * Perform critical part of code.
     */
    public void criticalSection(Guardian myGuard)
        throws SecurityException
    {
        myGuard.checkPermission(new BasicPermission("test"));
    }
}

        

如您所見，這段代碼有些復(fù)雜。為了能理解它，您需要理解異常處理。 這可能不是問題，因?yàn)榻^大多數(shù)Java開發(fā)者都知道如何處理異常。 用這種方式，您不需要太擔(dān)心組件的生存方式問題， 因?yàn)橐坏┪覀儾恍枰鼤r，就釋放了它。

這種方式的主要不利之處是增加了異常處理代碼，因?yàn)檩^為復(fù)雜。 為了能將復(fù)雜度降到最低，讓代碼更易于維護(hù)，我們把工作代碼提取出來，放在另一個方法中。 請記住在try語句塊中，我們想得到多少組件的引用，就可以得到多少。

這種方式的主要好處是您可以更有效率地管理組件引用。 同樣，如果您使用的是ThreadSafe組件，就沒有實(shí)質(zhì)差別，但如果您使用的是組件池里的組件時，就有差別了。 在每次您使用一個組件，取得一個新的引用時，有一點(diǎn)輕微的開銷，但是被迫創(chuàng)建一個新的組件實(shí)例的可能性大大降低。

像初始化和銷毀的方式一樣，您也必須了解一個微妙的差別。 如果管理器找不到組件，異常處理的方式不會讓程序在初始化時失敗掉。 如前所述，這并不是完全沒好處的。 很多時候，您希望某個組件存在，但是如果期望的組件不存在，程序也不需要失敗掉。