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 activation.xml assembly.xml classpath.xml containers.xml dictionary.xml export.xml extensions.xml faq.xml install.xml list.xml logging.xml support.xml
Date Tue, 06 Aug 2002 07:32:24 GMT
mcconnell    2002/08/06 00:32:24

  Modified:    assembly/src/xdocs activation.xml assembly.xml classpath.xml
                        containers.xml dictionary.xml export.xml
                        extensions.xml faq.xml install.xml list.xml
                        logging.xml support.xml
  Log:
  General documentation updating spelling, etc.
  
  Revision  Changes    Path
  1.2       +5 -3      jakarta-avalon-excalibur/assembly/src/xdocs/activation.xml
  
  Index: activation.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/activation.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- activation.xml	21 Jul 2002 05:04:10 -0000	1.1
  +++ activation.xml	6 Aug 2002 07:32:23 -0000	1.2
  @@ -14,14 +14,14 @@
       </section>
       <section name="Startup">
   <p>
  -On invocation of startup at the kernel level, the root container is started, resulting
in the assessment of each profile.  If the profile is declared with the activate attribute
as TRUE, Merlin will invoke instantiation of the service during the startup phase.  Instantation
will be following by startup of the component at which time the compoennt instance will be
supplied with a service manager (or component manager). Service to which the target component
is dependent will not be activated until the target invokes lookup on the supplied service
manager.  Merlin's service/compoennt manager implemetation holds refeences to the resource
and as such, can instantiate services on demand - or not at all if the dependent service is
not required within a particular session.
  +On invocation of startup at the kernel level, the root container is started, resulting
in the assessment of each profile.  If the profile is declared with the activate attribute
as TRUE, Merlin will invoke instantiation of the service during the startup phase.  Instantiation
will be following by startup of the component at which time the component instance will be
supplied with a service manager (or component manager). Service to which the target component
is dependent will not be activated until the target invokes lookup on the supplied service
manager.  Merlin's service/component manager implementation holds references to the resource
and as such, can instantiate services on demand - or not at all if the dependent service is
not required within a particular session.
   </p>
   <p>If no components request explicit activation, Merlin will simply continue with
a normal shutdown process.
   </p>
       </section>
       <section name="Shutdown">
   <p>
  -Shutdown is normally initiated by the kernel resulting in the orderly shutdown of running
services followed by shutdown of the container hierachy.  Shutdown signals both the halting
of execution of a service and the disposal of service and container resources. 
  +Shutdown is normally initiated by the kernel resulting in the orderly shutdown of running
services followed by shutdown of the container hierarchy.  Shutdown signals both the halting
of execution of a service and the disposal of service and container resources. 
   </p>
       </section>
   
  @@ -34,6 +34,8 @@
     </footer>
   
   </document>
  +
  +
   
   
   
  
  
  
  1.4       +13 -11    jakarta-avalon-excalibur/assembly/src/xdocs/assembly.xml
  
  Index: assembly.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/assembly.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- assembly.xml	2 Aug 2002 09:34:56 -0000	1.3
  +++ assembly.xml	6 Aug 2002 07:32:23 -0000	1.4
  @@ -74,7 +74,7 @@
   services it is dependent on.
   --&gt;</i></font>
   
  -&lt;component-info&gt;
  +&lt;type&gt;
   
   
     <font color="gray"><i>&lt;!--
  @@ -175,12 +175,12 @@
   
   
     <font color="gray"><i>&lt;!-- 
  -  Declaration of the set of dependecies that this component type has on 
  +  Declaration of the set of dependencies that this component type has on 
     component suppliers.  Dependency declarations define the role name 
     that the component will use to access a service via a service
     or component manager.  The service element identifies a service 
  -  descriptor that is publised by a potential supplier component. 
  -  A dependecy may be declared as optional by setting the optional 
  +  descriptor that is published by a potential supplier component. 
  +  A dependency may be declared as optional by setting the optional 
     attribute value to TRUE.  The default value for optional is FALSE.
     --&gt;</i></font>
   
  @@ -189,7 +189,7 @@
       <font color="gray"><i>&lt;!-- 
       A dependecy declaration. In the following example the optional 
       attribute is redundant as it is equivalent to the default value
  -    but is included here for completness.
  +    but is included here for completeness.
       --&gt;</i></font>
   
       &lt;dependency optional="<font color="darkred">FALSE</font>"&gt;
  @@ -233,7 +233,7 @@
         A phase declares the lifecycle phase interface implement by this component type
         under the &lt;reference&gt; element.  A phase declaration may also include
an 
         &lt;attributes&gt; declaration.  Phase handlers (extensions) will be applied
in 
  -      the same order as the declarations appear here - and will be deomissioning in 
  +      the same order as the declarations appear here - and will be decommissioned in 
         reverse order.
         --&gt;</i></font>
   
  @@ -272,7 +272,7 @@
   
       &lt;/extensions&gt;
   
  -  &lt;/component-info&gt;
  +  &lt;/type&gt;
   
   </pre>
   
  @@ -313,7 +313,7 @@
           Apply the following configuration when instantiating the component.  This configuration
           will be applied as the primary configuration in a cascading configuration chain.
 A 
           type may declare a default configuration under a "classname".xconfig file that
will be 
  -        used to dereference any configuration requests not resolvable by the configuration

  +        used to de-reference any configuration requests not resolvable by the configuration

           supplied here.
           --&gt;</i></font>
   
  @@ -322,7 +322,7 @@
           &lt;/configuration&gt;
   
           <font color="gray"><i>&lt;!--
  -        The parameterization criteria from this instance of the component type.
  +        The parameterisation criteria from this instance of the component type.
           --&gt;</i></font>
   
           &lt;parameters/&gt;
  @@ -335,7 +335,7 @@
   <ul>
    <li>a classname declared as a value of the dependency attribute "avalon.service.selector"</li>
    <li>a class named &lt;dependent-service-classname&gt;Selector within the
classpath</li>
  - <li>the default merlin service selector implemetation</li>
  + <li>the default Merlin service selector implementation</li>
   </ul>
   </p>
   <p>
  @@ -362,6 +362,8 @@
     </footer>
   
   </document>
  +
  +
   
   
   
  
  
  
  1.2       +48 -4     jakarta-avalon-excalibur/assembly/src/xdocs/classpath.xml
  
  Index: classpath.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/classpath.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- classpath.xml	21 Jul 2002 05:04:10 -0000	1.1
  +++ classpath.xml	6 Aug 2002 07:32:23 -0000	1.2
  @@ -6,8 +6,49 @@
       <author email="mcconnell@apache.org">Stephen McConnell</author>
     </properties>
     <body>
  -    <section name="Classpath Managment">
  -<p>A classpath declaration may occur at kernel and container scope.  A kernel classpath
is accessible by the root container and all subsidary containers.  A classpath declared at
container scope is accesible only to the immediate container in which the claspath is defined
and its subsidiary containers. An example of a classpath declaration is included below.</p>
  +   <section name="ClassLoader Management">
  +
  +     <p>Merlin provides two structures supporting the deinition of the class available
with the kernel    and containers.</p>
  +     <ul>
  +       <li><a href="#extensions">Extensions</a> - declaration of a set
of extension directories in which extension jar files are located</li>
  +       <li><a href="#classpath">Classpath</a> - declaration of classpath
strcutures that may be included within kernel or container scope.</li>
  +     </ul>
  +   
  +     <subsection name="Extensions Sub-System">
  +<a href="extension"/>
  +<p>A kernel may contain a single extensions element that declares the directories
in which extension jar files may be located.  Extensions are available to the root classloader
and as such are available to all containers.  An example of an extensions declaration is included
below.</p>
  +
  +
  +<pre>
  +  &lt;kernel&gt;
  +</pre>
  +
  +<p><font color="gray"><i>&lt;!-- 
  +Declaration of possibly multiple extension directories.  The extensions element may contain
multiple directory-set declarations, each containing possible multiple relative directory
paths.  On initialisation, the kernel classloader will be established with references to the
supplied directories.  Merlin will attempt to resolve any jar files declaring extension dependencies
based on the jar files included in the declared extension directories. 
  +--&gt;</i></font></p>
  +
  +<pre>
  +    &lt;extensions"&gt;
  +      &lt;dirset dir="<font color="darkred">.</font>"&gt;
  +        &lt;include name="<font color="darkred">dist</font>"/&gt;
  +        &lt;include name="<font color="darkred">lib</font>"/&gt;
  +      &lt;/dirset&gt;
  +    &lt;/extensions"&gt;
  +</pre>
  +
  +    <p><font color="gray"><i>&lt;!-- 
  +    Other kernel declarations.
  +    --&gt;</i></font></p>
  +
  +<pre>
  +  &lt;/kernel&gt;
  +</pre>
  +
  +    </subsection>
  +
  +    <subsection name="Classpath Managment">
  +<a href="extension"/>
  +<p>A classpath declaration may occur at kernel and container scope.  A kernel classpath
is accessible by the root container and all subsidiary containers.  A classpath declared at
container scope is accessible only to the immediate container in which the classpath is defined
and its subsidiary containers. An example of a classpath declaration is included below.</p>
   
   <pre>
     &lt;kernel&gt;
  @@ -55,7 +96,8 @@
     &lt;/kernel&gt;
   </pre>
   
  -    </section>
  +    </subsection>
  +   </section>
     </body>
     <footer>
       <legal>
  @@ -65,5 +107,7 @@
     </footer>
   
   </document>
  +
  +
   
   
  
  
  
  1.2       +6 -4      jakarta-avalon-excalibur/assembly/src/xdocs/containers.xml
  
  Index: containers.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/containers.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- containers.xml	17 Jul 2002 13:48:37 -0000	1.1
  +++ containers.xml	6 Aug 2002 07:32:23 -0000	1.2
  @@ -10,15 +10,15 @@
       <section name="Container">
   
         <p>The Merlin system provides support for a cascading containers. This model
enables component assemblers to associate jar files under a protected container scope where
each container is associated with its own classloader.</p>
  -      <p>Merlin will handle resolution of service dependencies for components contained
in containers by looking for explicitly declared components commencing within the local container,
and working progressively up the container hierachy.  If no explict solutions are resolved,
Merlin will attempt to build an implicit solution based on components declared in the respective
container classpath declarations.</p>
  +      <p>Merlin will handle resolution of service dependencies for components contained
in containers by looking for explicitly declared components commencing within the local container,
and working progressively up the container hierarchy.  If no explicit solutions are resolved,
Merlin will attempt to build an implicit solution based on components declared in the respective
container classpath declarations.</p>
   
       </section>
   
       <section name="Container Model">
   
  -      <p>A new container is created using a container model.  The model is the defintion
of the container, its classpath, and the profiles of the components it is resposible for managing.
 Container models are declared programatically or via an XML description.</p>
  +      <p>A new container is created using a container model.  The model is the defintion
of the container, its classpath, and the profiles of the components it is responsible for
managing.  Container models are declared programmatically or via an XML description.</p>
   
  -      <p><i>Minimilist container defintion.</i></p>
  +      <p><i>Minimilist container definition.</i></p>
   <pre>
       &lt;container name="<font color="darkred">root</font>"&gt;
         &lt;classpath&gt;
  @@ -42,3 +42,5 @@
     </footer>
   
   </document>
  +
  +
  
  
  
  1.2       +5 -4      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.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- dictionary.xml	6 Aug 2002 04:10:38 -0000	1.1
  +++ dictionary.xml	6 Aug 2002 07:32:23 -0000	1.2
  @@ -17,7 +17,7 @@
           <td><a href="assembly"/><p>Assembly</p></td>
   <td>
   <p>The recursive process of the resolution of dependencies declared by a component
with services provided by other components.</p>
  -<p>Merlin provides substantial support for the automation of component assembly.
 Under a kernel configuration a user can declare explicit components to be assembled.  Merlin
will attempt to put together solutions for component dependencies (service depedencies ad
extension dependecies) based on the availability of other explicit component declarations
together with implicit and packaged component declarations.  Implicit components are derived
from the manifest declarations within the jar files containing Packaged components are based
on a &lt;classname&gt;.xprofile resource packaged with a component type.</p>
  +<p>Merlin provides substantial support for the automation of component assembly.
 Under a kernel configuration a user can declare explicit components to be assembled.  Merlin
will attempt to put together solutions for component dependencies (service dependencies and
lifecycle extension dependencies) based on the availability of other explicit component declarations
together with implicit and packaged component declarations.  Implicit components are derived
from the manifest declarations within the jar files containing Packaged components are based
on a &lt;classname&gt;.xprofile resource packaged with a component type.</p>
           </td>
         </tr>
         <tr>
  @@ -45,7 +45,7 @@
           <td><a href="phase"/><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 differnet instantionation crieria - differented in terms
of the context, parameters, or configuration to be applied.  Profiles within Merlin may be
qualifed in terms of the statup policy and enabled status.  Startup policy inidicates that
a component shall be started on startup of the container or if activation of the component
can be deferred until it is requered.  Profile enablement policy simply declares if a profile
is enabled or not - non enabled component profiles will not be included as assembly candidates.</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>
           </td>
         </tr>
         <tr>
  @@ -66,4 +66,5 @@
       </legal>
     </footer>
   
  -</document>
  \ No newline at end of file
  +</document>
  +
  
  
  
  1.2       +4 -2      jakarta-avalon-excalibur/assembly/src/xdocs/export.xml
  
  Index: export.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/export.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- export.xml	21 Jul 2002 05:04:10 -0000	1.1
  +++ export.xml	6 Aug 2002 07:32:23 -0000	1.2
  @@ -8,7 +8,7 @@
     <body>
       <section name="Service Export">
   <p>
  -A Merlin kernel can be considered as a dynamic type in that it can export services depending
on the configuration it is supplied with.  The services established by a kernel are refered
to as "exported" services.  Exported service are encapsulated within ResourceDesignator and
as such, the client of a exported service is not aware of the instantiated state of the service.
 Client applications the utilise the exported service should contain to reference the ResourceDesignator
instance in prefernece to actual service instantiation where possible.  For example, a server
managing a collection of process process types could use a kernel to establish the process
component resources from which it could publish available processes.  On reception of a client
request for activation of a process, the server could establish a new process and apply a
service manager that maintains the resource reference.  This ensures that services are only
instantiated when actually needed.
  +A Merlin kernel can be considered as a dynamic type in that it can export services depending
on the configuration it is supplied with.  The services established by a kernel are referred
to as "exported" services.  Exported services are encapsulated within ResourceDesignator and
as such, the client of an exported service is not aware of the instantiated state of the service.
 Client applications utilise the exported service should contain to reference the ResourceDesignator
instance in preference to actual service instantiation where possible.  For example, a server
managing a collection of process types could use a kernel to establish the process component
resources from which it could publish available processes.  On reception of a client request
for activation of a process, the server could establish a new process and apply a service
manager that maintains the resource reference.  This ensures that services are only instantiated
when actually needed.
   </p>
       </section>
     </body>
  @@ -20,5 +20,7 @@
     </footer>
   
   </document>
  +
  +
   
   
  
  
  
  1.2       +58 -22    jakarta-avalon-excalibur/assembly/src/xdocs/extensions.xml
  
  Index: extensions.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/extensions.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- extensions.xml	21 Jul 2002 05:04:10 -0000	1.1
  +++ extensions.xml	6 Aug 2002 07:32:23 -0000	1.2
  @@ -2,37 +2,71 @@
   
   <document>
     <properties>
  -    <title>Extensions</title>
  +    <title>Lifecycle Extensions</title>
       <author email="mcconnell@apache.org">Stephen McConnell</author>
     </properties>
     <body>
  -    <section name="Extensions Sub-System">
  -<p>A kernel may contain a single extensions element that declares the directories
in which extension jar files may be located.  Extensions are available to the root classloader
and as such are available to all containers.  An example of an extensions declaration is included
below.</p>
  +    <section name="Lifecycle Extensions">
   
  +<p>Merlin provides support for pluggable lifecycle extensions.  Components can declare
dependencies on a lifecycle extension provider under the component type declaration using
the &lt;phases/&gt; element.  Component can declare themselves as providers of lifecycle
extension services via the &lt;extensions/&gt; element.</p>
  +
  +<p>The following XML type declaration depicts a component that declares a dependency
on two lifecycle phase extensions (Securable and Persistable) and in addition, declares itself
as a provider of lifecycle extension handling for the phase interface DemoExtension.</p>
   
   <pre>
  -  &lt;kernel&gt;
  -</pre>
  +  &lt;type&gt;
   
  -<p><font color="gray"><i>&lt;!-- 
  -Declaration of possibly multiple extension directories.  The extensions element may contain
multiple directory-set declations, each containing possible multiple relative directory paths.
 On initialization, the kernal classloader wil be established with references to the supplied
directories.  Merlin will attempt to resolve any jar files declaring extension dependecies
based on the jar files included in the declared extension directories. 
  ---&gt;</i></font></p>
  +    &lt;component&gt;
  +      &lt;name&gt;<font color="darkred">my-component</font>&lt;/name&gt;
  +      &lt;version&gt;<font color="darkred">1.2.1</font>&lt;/version&gt;
  +    &lt;/component&gt;
  +
  +    &lt;phases&gt;
  +
  +      <font color="gray"><i>&lt;!-- 
  +      A phase declares a lifecycle phase interface implement by this component type
  +      under the &lt;reference&gt; element.  A phase declaration may also include
an 
  +      &lt;attributes&gt; declaration.  Phase handlers (extensions) will be applied
to
  +      this component in the same order as the declarations appear here.  During 
  +      component decommissioning the phase order will be reversed.
  +      --&gt;</i></font>
  +
  +      &lt;phase&gt;
  +        &lt;reference type="<font color="darkred">org.apache.security.Securable</font>"/&gt;
  +      &lt;/phase&gt;
  +      &lt;phase&gt;
  +        &lt;reference type="<font color="darkred">org.apache.db.Persistable</font>"/&gt;
  +      &lt;/phase&gt;
  +
  +    &lt;/phases&gt;
  +
  +    <font color="gray"><i>&lt;!-- 
  +    Components may optionally declare their ability to provide extension handling.  An
  +    extension is equivalent to a phase handler.  
  +    --&gt;</i></font>
  +
  +    &lt;extensions&gt;
  +
  +      <font color="gray"><i>&lt;!-- 
  +      If a component type declares an extension, the component implementation 
  +      MUST implement the <a href="api/assembly/org/apache/excalibur/merlin/assembly/resource/Extension.html">Extension</a>
interface. 
  +      Possible stage attributes values include CREATE, DESTROY, ACCESS, RELEASE, 
  +      INNER, OUTER and ALL.  The INNER attribute value is equivalent to both 
  +      ACCESS and RELEASE.  The OUTER attribute value is equivalent to CREATE and 
  +      DESTORY.  The ALL value is equivalent to both INNER and OUTER.  
  +      --&gt;</i></font>
  +
  +      &lt;extension stage="ALL"&gt;
  +        &lt;reference type="<font color="darkred">org.apache.excalibur.playground.DemoExtension</font>"/&gt;
  +        &lt;attributes&gt;
  +          &lt;attribute key="<font color="darkred">status</font>" value="<font
color="darkred">experimental</font>"/&gt;
  +      &lt;/attributes&gt;
   
  -<pre>
  -    &lt;extensions"&gt;
  -      &lt;dirset dir="<font color="darkred">.</font>"&gt;
  -        &lt;include name="<font color="darkred">dist</font>"/&gt;
  -        &lt;include name="<font color="darkred">lib</font>"/&gt;
  -      &lt;/dirset&gt;
  -    &lt;/extensions"&gt;
  -</pre>
  +      &lt;/extension&gt;
   
  -    <p><font color="gray"><i>&lt;!-- 
  -    Other kernel declarations.
  -    --&gt;</i></font></p>
  +    &lt;/extensions&gt;
  +
  +  &lt;/type&gt;
   
  -<pre>
  -  &lt;/kernel&gt;
   </pre>
   
       </section>
  @@ -45,5 +79,7 @@
     </footer>
   
   </document>
  +
  +
   
   
  
  
  
  1.4       +6 -4      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.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- faq.xml	2 Aug 2002 09:34:56 -0000	1.3
  +++ faq.xml	6 Aug 2002 07:32:23 -0000	1.4
  @@ -19,16 +19,16 @@
   
       <subsection name="What's the difference between Merlin and Phoenix?">
   
  -<p>Merlin and Phoenix can be considered to be derived from the same family in terms
of architecture and notions of "what a component is".  Both Merlin and Phoenix leverage meta-information
about a type of component (the .xinfo resource).  Meta information used by Phoenix is described
as a &lt;block&gt; whereas Merlin uses the more general &lt;component-info&gt;
model.  Both models are relatively equivalent and it is expected that Phoenix will be migrating
to a common &lt;component-info&gt; schema in the near future.  With this in place,
Phoenix based components will be usable within Merlin providing the compoennts do not use
Phoenix specific interfaces or classes.  Typically, the two aspect to watch for on Phoenix
based components that limit portability are (a) references to the class BlockContext (which
can be eliminated by using the context key instead of Phoenix specific context accessors),
and (b), the usage of the BlockListener and ApplicationListener interfaces (both representing
Phoenix specific extensions).</p>
  +<p>Merlin and Phoenix can be considered to be derived from the same family in terms
of architecture and notions of "what a component is".  Both Merlin and Phoenix leverage meta-information
about a type of component (the .xinfo resource).  Meta information used by Phoenix is described
as a &lt;block&gt; whereas Merlin uses the more general &lt;component-info&gt;
model.  Both models are relatively equivalent and it is expected that Phoenix will be migrating
to a common &lt;component-info&gt; schema in the near future.  With this in place,
Phoenix based components will be usable within Merlin providing the components do not use
Phoenix specific interfaces or classes.  Typically, the two aspect to watch for on Phoenix
based components that limit portability are (a) references to the class BlockContext (which
can be eliminated by using the context key instead of Phoenix specific context accessors),
and (b), the usage of the BlockListener and ApplicationListener interfaces (both representing
Phoenix specific extensions).</p>
   
   <p>Aside from these differences, Phoenix and Merlin are very similar - they both
handle service assembly, activation, and decommissioning.  Differences appear with respect
to the approaches used and the overhead implied on a user. Merlin makes every attempt to minimise
that level of information required to assemble a service model.  For example, Merlin does
not require explicit linking of components under an assembly file.  Furthermore, Merlin provides
a framework for defaults management enabling automatic service establishment.  Perhaps most
significant is the design objective of Merlin to provide simple programmatic embedding of
kernels and containers into other components and foreign systems.  Relative to Merlin, Phoenix
is much more static in that it requires a significantly higher level of engagement in the
establishment of a service model.  On the other-hand, Phoenix contains additional features
not present in Merlin - in particular JMX support.</p>
   
  -<p>At the overall architecture level Phonenix provides support for pluggable facilities
(cut-down components) to provide support for core servises towards a set of applications.
 Merlin's goes further by providing the ability for real "component" based facilities model
via embedded <a href="api/assembly/org/apache/excalibur/merlin/kernel/Kernel.html">kernels</a>
that export services backed by a flexible hierarchical <a href="api/assembly/org/apache/excalibur/merlin/container/Container.html">container</a>
structure.  Based simply on available functionality, Phoenix, it's the choice when selecting
an app-server. Merlin on the other-hand demands substantially less engagement by the end-user
and delivers a commensurate reduction in support overhead.</p>
  +<p>At the overall architecture level Phoenix provides support for pluggable facilities
(cut-down components) to provide support for core services towards a set of applications.
 Merlin's goes further by providing the ability for real "component" based facilities model
via embedded <a href="api/assembly/org/apache/excalibur/merlin/kernel/Kernel.html">kernels</a>
that export services backed by a flexible hierarchical <a href="api/assembly/org/apache/excalibur/merlin/container/Container.html">container</a>
structure.  Based simply on available functionality, Phoenix, it's the choice when selecting
an app-server. Merlin on the other-hand demands substantially less engagement by the end-user
and delivers a commensurate reduction in support overhead.</p>
   
         </subsection>
   
         <subsection name="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 conterkit by providing explicit declaration of lifecycle extension depedencies,
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 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 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>
   
  @@ -48,6 +48,8 @@
     </footer>
   
   </document>
  +
  +
   
   
   
  
  
  
  1.3       +6 -4      jakarta-avalon-excalibur/assembly/src/xdocs/install.xml
  
  Index: install.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/install.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- install.xml	2 Aug 2002 09:34:56 -0000	1.2
  +++ install.xml	6 Aug 2002 07:32:23 -0000	1.3
  @@ -8,9 +8,9 @@
     <body>
       <section name="Installation">
   
  -    <subsection name="Dependecies">
  +    <subsection name="Dependencies">
   <p>
  -Installation of Merlin assumes you have Ant 1.4 or later installled on you machine.
  +Installation of Merlin assumes you have Ant 1.4 or later installed on you machine.
   </p>
   <p><a href="http://jakarta.apache.org/ant/index.html">Ant Home Page</a></p>
   
  @@ -18,7 +18,7 @@
       <subsection name="CVS Repository">
   
   <p>
  -The Merlin distribution is available via the Apache CVS server. To access the server, simply
use the following commands (if you are using a GUI CVS client, configure it appropriatly):
  +The Merlin distribution is available via the Apache CVS server. To access the server, simply
use the following commands (if you are using a GUI CVS client, configure it appropriately):
   </p>
   
   <pre>
  @@ -61,5 +61,7 @@
     </footer>
   
   </document>
  +
  +
   
   
  
  
  
  1.2       +2 -3      jakarta-avalon-excalibur/assembly/src/xdocs/list.xml
  
  Index: list.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/list.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- list.xml	21 Jul 2002 05:04:10 -0000	1.1
  +++ list.xml	6 Aug 2002 07:32:23 -0000	1.2
  @@ -9,7 +9,7 @@
   
       <section name="Mailing Lists">
   <p>
  -Merlin is part of the Apache Avalon Project. The <a href="http://jakarta.apache.org/site/mail2.html#Avalon">Avalon
User list</a> is available for general questions and queries relating to Avalon iniatives.
  +Merlin is part of the Apache Avalon Project. The <a href="http://jakarta.apache.org/site/mail2.html#Avalon">Avalon
User list</a> is available for general questions and queries relating to Avalon initiatives.
   </p>
       </section>
   
  @@ -22,5 +22,4 @@
     </footer>
   
   </document>
  -
   
  
  
  
  1.4       +12 -10    jakarta-avalon-excalibur/assembly/src/xdocs/logging.xml
  
  Index: logging.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/logging.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- logging.xml	2 Aug 2002 09:34:56 -0000	1.3
  +++ logging.xml	6 Aug 2002 07:32:23 -0000	1.4
  @@ -8,11 +8,11 @@
     <body>
   
       <section name="Logging Sub-System">
  -<p>Logging services build above the Avalon framework abstract logging infrastructure.
 Merlin provides the mechanisms through which logging hierachies can be created, logging prioprities
assigned, and definition of log event output targets.  Logging directives may be includes
at the kernel, container and component levels.</p>
  +<p>Logging services build above the Avalon framework abstract logging infrastructure.
 Merlin provides the mechanisms through which logging hierarchies can be created, logging
priorities assigned, and definition of log event output targets.  Logging directives may be
includes at the kernel, container and component levels.</p>
       </section>
   
       <section name="Kernel Directives">
  -<p>A kernel may be configured with an option logging system creation directive. 
The logging element declares the application wide default logging priority. A target element
enables defintion of a logging file to which log entries will be directed.  The target name
attribute is the name referenced by category elements defined within the loggers element.
Child category declarations must include a name (the logging catagory), and may optionally
include a target and a priority attribute. The target defaults of "default" which corresponds
to a internal default logging target that issue messages to System.out (unless overriden by
a target named default). If the target is declared inside a catagory element, it must refer
to a named target element.  The priority attribute may container one of the values <code>DEBUG</code>,
<code>INFO</code>, <code>WARN</code> or <code>ERROR</code>.
 The target must contain a single file element with the attribute <code>location</code>
the corresponds to the name of the logging file.</p>
  +<p>A kernel may be configured with an option logging system creation directive. 
The logging element declares the application wide default logging priority. A target element
enables definition of a logging file to which log entries will be directed.  The target name
attribute is the name referenced by category elements defined within the loggers element.
Child category declarations must include a name (the logging category), and may optionally
include a target and a priority attribute. The target defaults of "default" which corresponds
to a internal default logging target that issue messages to System.out (unless overridden
by a target named default). If the target is declared inside a category element, it must refer
to a named target element.  The priority attribute may container one of the values <code>DEBUG</code>,
<code>INFO</code>, <code>WARN</code> or <code>ERROR</code>.
 The target must contain a single file element with the attribute <code>location</code>
the corresponds to the name of the logging file.</p>
   
   <pre>
     &lt;kernel&gt;
  @@ -40,7 +40,7 @@
   
       <p><font color="gray"><i>&lt;!-- 
       Multiple categories may be declared - each category defines a priority and target
  -    to be used for the respective caegory.  Category names are scoped relative to the 
  +    to be used for the respective category.  Category names are scoped relative to the

       container.  In this context the container is the kernel.  As such a category name
       of "logging" translates to a full logging category path of "kernel.logging".  The 
       logging element may contain priority and target attribute values.  These values
  @@ -74,8 +74,8 @@
       <li><b>installer</b>, the classloader that handles initial model
construction</li>
       <li><b>installer.types</b>, type registration</li>
       <li><b>installer.types.builder</b>, type creation</li>
  -    <li><b>loader</b>, the classloader essigned to the kernel following
bootstrap installation</li>
  -    <li><b>export</b>, provides reports on the services exprted by the
kernel</li>
  +    <li><b>loader</b>, the classloader assigned to the kernel following
bootstrap installation</li>
  +    <li><b>export</b>, provides reports on the services exported by the
kernel</li>
       </ul>
       </p>    
   
  @@ -84,7 +84,7 @@
   
       <section name="Container Directives">
   
  -    <p>A kernel contains a single root container.  The name of the container establishes
a top level logging category name. Categories defined within the scope of a container are
always relative to the enclosing container path name.  For example, a logging category of
"assembly" inside a root container named "root" is definting parameters for the logging category
"root.assembly".  Sub-containers within a container hierachy for a category name path.  For
example, if a container name "sub" is included in a container named "root", the containers
logging category will be "root.sub".  Logging category declarations scoped within a container
will be created relative to the contains rerived category path.</p>
  +    <p>A kernel contains a single root container.  The name of the container establishes
a top level logging category name. Categories defined within the scope of a container are
always relative to the enclosing container path name.  For example, a logging category of
"assembly" inside a root container named "root" is defining parameters for the logging category
"root.assembly".  Sub-containers within a container hierarchy for a category name path.  For
example, if a container name "sub" is included in a container named "root", the containers
logging category will be "root.sub".  Logging category declarations scoped within a container
will be created relative to the contains category path.</p>
   
       <p>Logging sub-categories within the container category include:
       <ul>
  @@ -93,7 +93,7 @@
       <li><b>loader.types.builder</b>, type creation</li>
       <li><b>assembly</b>, actions relating to auto-assembly of components</li>
       <li><b>assembly.selector</b>, the service selection sub-system</li>
  -    <li><b>provider</b>, component resoruce provider sub-system</li>
  +    <li><b>provider</b>, component resource provider sub-system</li>
       <li><b>provider</b>, component lifecycle handler sub-system</li>
       </ul>
       </p>    
  @@ -105,7 +105,7 @@
       &lt;container name="<font color="darkred">root</font>"&gt;
   </pre>
       <p><font color="gray"><i>&lt;!-- 
  -Multiple categories may be declared - each category defines a priority and target to be
used for the respective caegory.  Category names are scoped relative to the container.  As
such a category name of "logging" translates to a full logging category path of "root.logging".
 The logging element may contain priority and target attribute values.  These values will
overide the system wide defaults relative to kernel sub-categories. --&gt;</i></font>
  +Multiple categories may be declared - each category defines a priority and target to be
used for the respective category.  Category names are scoped relative to the container.  As
such a category name of "logging" translates to a full logging category path of "root.logging".
 The logging element may contain priority and target attribute values.  These values will
override the system wide defaults relative to kernel sub-categories. --&gt;</i></font>
       </p>
   
   <pre>
  @@ -132,7 +132,7 @@
       </section>
   
       <section name="Component Directives">
  -<p>Component scoped logging directives are relative to the enclosing componet profile
declaration.  The logging categories are component specific and will normally be documeted
as part of the component you are using.  The following example is the logging configuration
for the demonstration component included with the distribution.</p>
  +<p>Component scoped logging directives are relative to the enclosing component profile
declaration.  The logging categories are component specific and will normally be documented
as part of the component you are using.  The following example is the logging configuration
for the demonstration component included with the distribution.</p>
   
   <pre>
     &lt;kernel&gt;
  @@ -177,5 +177,7 @@
     </footer>
   
   </document>
  +
  +
   
   
  
  
  
  1.3       +5 -3      jakarta-avalon-excalibur/assembly/src/xdocs/support.xml
  
  Index: support.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/support.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- support.xml	2 Aug 2002 09:34:56 -0000	1.2
  +++ support.xml	6 Aug 2002 07:32:23 -0000	1.3
  @@ -28,7 +28,7 @@
   	<tr valign="top" bgcolor="lightgrey">
   		<td class="mini">0.7</td>
   		<td class="mini"><a href="http://home.osm.net/doc/collaboration/index.html">Collaboration
Framework</a></td>
  -		<td class="mini">Component providing support for the execution of collaborative
business processes in which the policy concerning rights and privaliges and the sequencing
of multiple participants is declared through DPML (Digital Product Modelling Language).</td></tr>
  +		<td class="mini">Component providing support for the execution of collaborative
business processes in which the policy concerning rights and privileges and the sequencing
of multiple participants is declared through DPML (Digital Product Modelling Language).</td></tr>
   	<tr valign="top" bgcolor="lightgrey">
   		<td class="mini">0.8</td>
   		<td class="mini"><a href="http://home.osm.net/doc/community/index.html">Community
Framework</a></td>
  @@ -40,7 +40,7 @@
   	<tr valign="top" bgcolor="lightgrey">
   		<td class="mini">0.9</td>
   		<td class="mini"><a href="http://home.osm.net/doc/gateway/index.html">Gateway</a></td>
  -		<td class="mini">Services supporting user centric web based interaction with business
processes, tasks, workspaces, and service directories.  The Gateway services defines a suite
of servlet that provide a consitent view of a user's business context, available resources,
and the characteristics, features, and policies of the resources available and in use.</td></tr>
  +		<td class="mini">Services supporting user centric web based interaction with business
processes, tasks, workspaces, and service directories.  The Gateway services defines a suite
of servlet that provide a consistent view of a user's business context, available resources,
and the characteristics, features, and policies of the resources available and in use.</td></tr>
     </table>
     <p><img src="/images/nothing.gif" border="0"/></p>
       </section>
  @@ -53,5 +53,7 @@
     </footer>
   
   </document>
  +
  +
   
   
  
  
  

--
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