avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From blorit...@apache.org
Subject cvs commit: jakarta-avalon-excalibur/fortress/src/xdocs design-notes.xml
Date Tue, 04 Feb 2003 20:00:42 GMT
bloritsch    2003/02/04 12:00:42

  Modified:    fortress/src/xdocs design-notes.xml
  update the docs accordingly
  Revision  Changes    Path
  1.2       +43 -5     jakarta-avalon-excalibur/fortress/src/xdocs/design-notes.xml
  Index: design-notes.xml
  RCS file: /home/cvs/jakarta-avalon-excalibur/fortress/src/xdocs/design-notes.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- design-notes.xml	21 Jan 2003 21:12:00 -0000	1.1
  +++ design-notes.xml	4 Feb 2003 20:00:42 -0000	1.2
  @@ -10,7 +10,7 @@
       <s1 title="Fortress Design Notes">
  -	    Fortress has two design goals: facilitate heirarchical containers and
  +        Fortress has two design goals: facilitate heirarchical containers and
           take management functions outside of the critical path. The critical
           path is the code execution path that is required to find and use a
           component. Fortress assumes that the developer has explicit knowledge of
  @@ -19,7 +19,7 @@
           force that upon the developer.
         <s2 title="Asynchronous Management">
  -	    <p>
  +        <p>
             Due to the long startup times of certain components like the
             DataSourceComponent ECM based code suffered from slowness. The problem
             was also made worse by the delayed loading and running of components.
  @@ -27,7 +27,7 @@
             up--which made problems for components that needed to be started
  -	    <p>
  +        <p>
             Fortress makes use of the Event package's CommandManager so that all
             components can be started up immediately, but it is done in the
             background. That means that components are still starting while
  @@ -45,7 +45,7 @@
         <s2 title="Hierarchical Containers">
  -	    <p>
  +        <p>
             Part of the design concept for Fortress heirarchical containers is to
             use a ContainerManager to make sure all the necessary services are set
             up and running. For example, the Fortress container needs a
  @@ -92,6 +92,44 @@
               we will have a proper meta model.
  +      </s2>
  +      <s2 title="Smooth Migration for Component Lookup">
  +        <p>
  +          Due to the fact there are many ways of implementing the "preferred
  +          practices" for role naming, different components make assumptions
  +          about their environment.  The chief problem with these assumptions
  +          is that it reduces the availability for which components can work
  +          with each other.  Some components expect only one component to be
  +          mapped, while another component may expect to lookup choices in
  +          a ServiceSelector, while yet another may expect to find it via a
  +          stylized entry.  To recap, the supported lookup styles are:
  +        </p>
  +        <ul>
  +          <li>lookup(MyComponent.ROLE)</li>
  +          <li>lookup(MyComponent.ROLE + "Selector").select(hint)</li>
  +          <li>lookup(MyComponent.ROLE + "/" + hint)</li>
  +        </ul>
  +        <p>
  +          In the first case, the component that requires an external component
  +          asks for the mapped component via the role name.  It expects only
  +          one component to be mapped.  If Fortress has multiple components
  +          available, it will only return the default version.  The default
  +          version is the first entry in the configuration file, unless you
  +          add the magic attribute "default" with the value "true".  The last
  +          component for the role with that attribute is the default value.
  +        </p>
  +        <p>
  +          In the second case, the component expects to be able to select the
  +          component from a ServiceSelector, mapped to the ROLE + "Selector"
  +          entry.  Fortress will manufacture a ServiceSelector for you, and
  +          all will be as expected.
  +        </p>
  +        <p>
  +          In the last case, the component expects to be able to look up the
  +          component based on the ROLE and the hint combined.  The magic
  +          separator is the "/" character.  Fortress will be able to interpret
  +          that and skip the ServiceSelector step.
  +        </p>

To unsubscribe, e-mail: avalon-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-cvs-help@jakarta.apache.org

View raw message