avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mcconn...@apache.org
Subject cvs commit: jakarta-avalon-excalibur/assembly/src/xdocs dictionary.xml faq.xml
Date Sat, 24 Aug 2002 16:01:15 GMT
mcconnell    2002/08/24 09:01:15

  Modified:    assembly/src/xdocs dictionary.xml faq.xml
  Log:
  General updating of xdocs.
  
  Revision  Changes    Path
  1.4       +5 -10     jakarta-avalon-excalibur/assembly/src/xdocs/dictionary.xml
  
  Index: dictionary.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/dictionary.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- dictionary.xml	21 Aug 2002 17:00:52 -0000	1.3
  +++ dictionary.xml	24 Aug 2002 16:01:15 -0000	1.4
  @@ -37,14 +37,7 @@
           </td>
         </tr>
         <tr>
  -        <td><a href="phase"/><p>Phase</p></td>
  -        <td>
  -<p>A reference to a behavioural extension - sometimes referred to as a lifecycle
phase or lifecycle stage.</p>
  -<p>Component types can declare their dependence on providers of lifecycle extensions
through a <a href="api/meta/org/apache/excalibur/meta/info/StageDescriptor.html">StageDescriptor</a>.
 Examples of a lifecycle phase includes notions such as <code>Exploitable</code>,
<code>Demonstratable</code>, or <code>Persistable</code>.  These interfaces
represent extended behavioural cycles supported by a component, and as such, dependencies
that a component has towards phase extension providers.  It is the responsibility of a container
to resolve and provide an appropriate phase provider to service the phase dependencies published
by a component.</p>
  -        </td>
  -      </tr>
  -      <tr>
  -        <td><a href="phase"/><p>Profile</p></td>
  +        <td><a href="profile"/><p>Profile</p></td>
           <td>
   <p>A <a href="api/assembly/org/apache/excalibur/merlin/model/Profile.html">Profile</a>
is a description of a component <a href="api/meta/org/apache/excalibur/meta/info/Type.html">Type</a>
instantiation criteria.</p> 
   <p>A type may have many different instantiation criteria - different in terms of
the context, parameters, or configuration to be applied.  Profiles within Merlin may be qualified
in terms of the startup policy and enabled status.  Startup policy indicates that a component
shall be started on startup of the container or if activation of the component can be deferred
until it is required.  Profile ennoblement policy simply declares if a profile is enabled
or not - non enabled component profiles will not be included as assembly candidates.</p>
  @@ -54,7 +47,9 @@
           <td><a href="stage"/><p>Stage</p></td>
           <td>
   <p>A stage is defined as one of the well-know lifecycle step that a component passed
though during deployment.</p>
  -<p>These stages include <a href="api/meta/org/apache/excalibur/meta/info/ExtensionDescriptor.html#CREATE">create</a>,
<a href="api/meta/org/apache/excalibur/meta/info/ExtensionDescriptor.html#ACCESS">access</a>,
<a href="api/meta/org/apache/excalibur/meta/info/ExtensionDescriptor.html#RELEASE">release</a>
and <a href="api/meta/org/apache/excalibur/meta/info/ExtensionDescriptor.html#DESTROY">destroy</a>.
 The creation and destruction stages are referred to within the Merlin environment as outer-stages
whereas access and release are referred to as inner-stages.  Stages represent the points at
which lifecycle extensions can be applied to the core component model.  The meta-info model
used within Merlin allows for a component to declare itself as a provider of a lifecycle <a
href="#phase">phase</a> extension.  The meta-info <a href="api/meta/org/apache/excalibur/meta/info/ExtensionDescriptor.html">ExtensionDescriptor</a>
is a declaration of a phase interface together with the stages that the extension should applied
under.</p>
  +<p>These stages include creation, access, relase, and destruction. The creation and
destruction stages are referred to within the Merlin environment as outer-stages whereas access
and release are referred to as inner-stages.  Stages represent the points at which lifecycle
extensions can be applied to the core component model.  The meta-info model used within Merlin
allows for a component to declare itself as a provider of a lifecycle <a href="#stage">stage</a>
extension.</p>
  +<p>The meta-info <link href="http://jakarta.apache.org/avalon/excalibur/meta/api/org/apache/excalibur/meta/info/ExtensionDescriptor.html">ExtensionDescriptor</link>
is a declaration of a phase interface provider.</p>  
  +<p>The meta-info <link href="http://jakarta.apache.org/avalon/excalibur/meta/api/org/apache/excalibur/meta/info/StageDescriptor.html">StageDescriptor</link>
is a declaration of a phase interface dependency.</p>
           </td>
         </tr>
       </table>
  
  
  
  1.7       +3 -3      jakarta-avalon-excalibur/assembly/src/xdocs/faq.xml
  
  Index: faq.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/faq.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- faq.xml	21 Aug 2002 17:00:52 -0000	1.6
  +++ faq.xml	24 Aug 2002 16:01:15 -0000	1.7
  @@ -13,7 +13,7 @@
   
   <p>Merlin and Fortress are very similar in that they both address the requirement
for an embeddable component container.  Merlin and Fortress differ in terms of the requirements
that they meet.  Fortress focuses on the needs related to frequent service activation requests
based on service interface request supplied by a client to a service or component manager.
 Merlin on the other-hand is more concerned with complex service management systems establishment.</p>
   
  -<p>Fortress contains a more complete set of service/component manager in terms of
<i>lifestyle</i> handling than Merlin, however, the functionality inside Fortress
concerning formal dependency management and service assembly is relatively weak.  Relative
to the Merlin architecture, Fortress can be considered as a type of container.  Looking forward,
it would be desirable for Merlin to be able to include Fortress as a type of container (i.e.
have Fortress implement the Merlin <a href="api/assembly/org/apache/excalibur/merlin/container/Container.html">Container</a>
interface).  This would expand the service lifestyle models available.  Another approach would
be to merge the Fortress and Merlin developments, however there are important issues relating
to assumptions made at the level of service/component manager lookup request and semantics
related to component/service selectors that remain open.</p>
  +<p>Fortress and Merlin contain an equivalent set of service/component manager in
terms of <i>lifestyle</i>. Relative to the Merlin architecture, Fortress can be
considered as a type of container.  Looking forward, it would be desirable for Merlin to be
able to include Fortress as a type of container (i.e. have Fortress implement the Merlin <a
href="api/assembly/org/apache/excalibur/merlin/container/Container.html">Container</a>
interface).  This would expand support for th elegacy ECM resources including role-management
approaches used in this context.</p>
   
   <p>User's familiar with the ECM framework will find may aspects of Fortress familiar.
 User's that have experience problems related to larger scale activation ordering, complex
configuration, or context dependent components will find Merlin more appropriate to their
needs.</p>
   
  @@ -30,7 +30,7 @@
         </s2>
   
         <s2 title="What's the difference between Containerkit and the Merlin Meta-Model?">
  -<p>The meta model defined in both Containerkit and Merlin separates out the notion
of type related meta-info from the criteria for instantiation - commonly referred to a meta-data.
The Merlin meta-info API is basically a superset of the containerkit API.  The Merlin meta-info
model goes beyond containerkit by providing explicit declaration of lifecycle extension dependencies,
and lifecycle extension handlers.</p>
  +<p>The meta model defined in both Containerkit and Merlin separates out the notion
of type related meta-info from the criteria for instantiation - commonly referred to a meta-data.
The meta-info API used by Merlin is basically a superset of the containerkit API.  The Merlin
meta-info model goes beyond containerkit by providing explicit declaration of lifecycle extension
dependencies, and lifecycle extension handlers.</p>
   
   <p>The Merlin API used more human friendly naming conventions (e.g. a type is referred
to a <a href="api/meta/org/apache/excalibur/meta/info/Type.html">Type</a>, a component
profile at the meta-data level is called a <a href="api/assembly/org/apache/excalibur/merlin/model/Profile.html">Profile</a>,
the association between profiles is called an <a href="api/assembly/org/apache/excalibur/merlin/model/Association.html">Association</a>
- whereas containerkit references the same entries using more technically oriented naming
conventions - ComponentInfo, ComponentMetaData and DependencyMetaData respectively).  Aside
from naming conventions, the Merlin meta-info model includes a method through which a client
can assess a default configuration associated and packaged with the type, allows dynamic addition
of association, and includes support for formal lifecycle extension management.</p>
   
  
  
  

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


Mime
View raw message