avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mcconn...@apache.org
Subject cvs commit: avalon-sandbox/merlin/merlin-smp/xdocs/starting/examples/afs index.xml
Date Tue, 08 Apr 2003 11:19:52 GMT
mcconnell    2003/04/08 04:19:52

  Modified:    merlin/merlin-smp/xdocs index.xml
               merlin/merlin-smp/xdocs/about benefits.xml features.xml
                        index.xml purpose.xml
               merlin/merlin-smp/xdocs/extensions/servlet index.xml
               merlin/merlin-smp/xdocs/merlin/appliance assembly.xml
                        index.xml lifestyle.xml
               merlin/merlin-smp/xdocs/merlin/block index.xml packaging.xml
               merlin/merlin-smp/xdocs/merlin/kernel cli.xml index.xml
                        nt.xml
               merlin/merlin-smp/xdocs/starting/examples/afs index.xml
  Log:
  Documentation updating.
  
  Revision  Changes    Path
  1.3       +5 -33     avalon-sandbox/merlin/merlin-smp/xdocs/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/index.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- index.xml	2 Apr 2003 15:51:51 -0000	1.2
  +++ index.xml	8 Apr 2003 11:19:51 -0000	1.3
  @@ -25,12 +25,7 @@
   
       <subsection name="Service Management Platform (SMP)">
   <p>
  -Merlin System is a service management platform based
  -on an advanced assembly engine.  If focus is to provide support
  -for the encapsulation of a set of components and services
  -within functional blocks.  Blocks enable the separation of
  -components as an implementation solutions, from services
  -established by respective components.
  +Merlin is a service management platform based on an advanced assembly engine.  Its focus
is to provide support for the encapsulation of a set of components and services within functional
blocks.  Blocks enable the separation of components as an implementation solutions from services
established by respective components.
        </p>
   
       </subsection>
  @@ -38,44 +33,21 @@
       <subsection name="Assembly Framework">
   
   <p>
  -The assembly engine is responsible for the management of the
  -the deployment of services provided by a component. 
  +The assembly engine is responsible for the management of the deployment of services provided
by a component. 
   </p>
   
   <p>
  -Components in the framework may have dependencies on services
  -provided by other components, which in turn may have
  -dependencies of their own.  In addition, components can
  -declare (as part of their meta-info) particular lifecycle
  -stages (such as initiation or configuration) and the type
  -of stage provider it needs to handle that stage.  So in
  -effect, components can be deployed with classic runtime
  -dependencies together with deployment dependencies (because
  -deployment stage providers are themselves components that 
  -may have their own deployment and runtime dependencies).
  +Components in the framework may have dependencies on services provided by other components,
which in turn may have dependencies of their own.  In addition, components can declare (as
part of their meta-info) particular lifecycle stages (such as initiation or configuration)
and the type of stage provider it needs to handle that stage.  So in effect, components can
be deployed with classic runtime dependencies together with deployment dependencies (because
deployment stage providers are themselves components that may have their own deployment and
runtime dependencies).
   </p>
   
   <p>
  -Assembly services include ordered deployment and
  -decommissioning, and a range of "lifestyle" handlers (things
  -like thread-safe, per-thread, singleton, transient, or
  -custom policies).  The package includes facilities for:
  -classloader management and cascading repositories for
  -types, templates, service definitions and appliance
  -instances (where an appliance is simply an instantiation of a
  -particular component deployment scenario). 
  +Assembly services include ordered deployment and decommissioning, and a range of "lifestyle"
handlers (things like thread-safe, per-thread, singleton, transient, or custom policies).
 The package includes facilities for: classloader management and cascading repositories for
types, templates, service definitions and appliance instances (where an appliance is simply
an instantiation of a particular component deployment scenario). 
   </p>
       </subsection>
   
       <subsection name="Meta Model">
   <p>
  -The meta model used in Merlin defines the notion of a component type.  A Type
  -defintion contains infromation about deployment and runtime dependecies together
  -with general attributes about the type and the Services the component type can 
  -provide. The Type and Service notions are complimented by a Profile which can be
  -viewed as a template deployment scenario.  Type, Service and Profile descriptions
  -can be packaged in jars files and used as the basic for automating component 
  -assembly and deployment. 
  +The meta model used in Merlin defines the notion of a component type.  A Type definition
contains information about deployment and runtime dependencies together with general attributes
about the type and services the component type can provide. The Type and Service notions are
complimented by a Profile which can be viewed as a template deployment scenario.  Type, Service
and Profile descriptions can be packaged in jars files and used as the basic for automating
component assembly and deployment. 
   </p>
   
       </subsection>
  
  
  
  1.2       +5 -5      avalon-sandbox/merlin/merlin-smp/xdocs/about/benefits.xml
  
  Index: benefits.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/about/benefits.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- benefits.xml	2 Apr 2003 15:51:52 -0000	1.1
  +++ benefits.xml	8 Apr 2003 11:19:51 -0000	1.2
  @@ -15,7 +15,7 @@
   
       <subsection name="Seperating Concerns">
   <p>
  -Every developer that has written a complex compoent based application has had to deal with
container-side programing. Given normal commerical pressures, it too easy to write code into
your application that has assumptions built into it concerning the requirements of the target
components.
  +Every developer that has written a complex component based application has had to deal
with container-side programming. Given normal commercial pressures, it too easy to write code
into your application that has assumptions built into it concerning the requirements of the
target components.
   </p>
   
   <p>
  @@ -41,11 +41,11 @@
   </source>
   
   <p>
  -The above container-side code is making a lot of assumptions about the component it is
deploying.  Firstly, it knows that the component log log enabled, contextualizable, and initializable.
This is problamatic becuase it means that the container-side code is dependent on the component
implementation.  If the component were to be changed so that it supported the configurable
semantics, there container-side code needs to be updated as well.  This is dangerouse because
it is easy for container-side to get out-of-sync with the component implementation - for example,
the container side code to some extent is dependent on a component properly checking if it
has been configured or not. A deeper and more important issue concerns component assembly
- if a component  is refactored to use other components, then the container-side code become
much more complex and much more closely tied to the set of compoents that make up the assembly.
  +The above container-side code is making a lot of assumptions about the component it is
deploying.  Firstly, it knows that the component is log enabled, contextualizable, and initializable.
This is problematic because it means that the container-side code is dependent on the component
implementation.  If the component were to be changed so that it supported the configurable
semantics, there container-side code needs to be updated as well.  This is dangerous because
it is easy for container-side to get out-of-sync with the component implementation - for example,
the container side code to some extent is dependent on a component properly checking if it
has been configured or not. A deeper and more important issue concerns component assembly
- if a component  is refactored to use other components, then the container-side code become
much more complex and much more closely tied to the set of components that make up the assembly.
   </p>
   
   <p>
  -The solution to the above is a framework that automates the process of component deployment.
 The end result is that container side code becomes independent of the the component deployment
strategy and component depedencies.
  +The solution to the above is a framework that automates the process of component deployment.
 The end result is that container side code becomes independent of the component deployment
strategy and component dependencies.
   </p>
   
   <p>Consider the following code fragment:</p>
  @@ -72,7 +72,7 @@
   </source>
   
   <p>
  -The above code demonstrates the elimination of knowlge about the component deployment strategy.
 All aspect concerning the component logging, configuration, parameterization, contexulization,
dependency composition, initialization, startup, shutdown and disposal are managed by the
engine.
  +The above code demonstrates the elimination of knowledge about the component deployment
strategy.  All aspect concerning the component logging, configuration, parameterization, contexulization,
dependency composition, initialization, startup, shutdown, and disposal are managed by the
engine.
   </p>
   
        </subsection>
  
  
  
  1.2       +4 -26     avalon-sandbox/merlin/merlin-smp/xdocs/about/features.xml
  
  Index: features.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/about/features.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- features.xml	2 Apr 2003 15:51:52 -0000	1.1
  +++ features.xml	8 Apr 2003 11:19:51 -0000	1.2
  @@ -13,44 +13,22 @@
       <section name="Features and Benefits">
         <subsection name="Composite Component Management">
           <p>
  -           Merlin provides support for the packaging and 
  -           deployment of composite components with a structure
  -           called a Block.  A block represents the association
  -           of resources to a containment hierachy within which 
  -           components are managed.  In addition, a block enables
  -           the seperation of a component assembly as implementation
  -           from the subset of services published by the block.
  +Merlin provides support for the packaging and deployment of composite components with a
structure called a Block.  A block represents the association of resources to a containment
hierarchy within which components are managed.  In addition, a block enables the separation
of a component assembly as implementation from the subset of services published by the block.
           </p>
         </subsection>
         <subsection name="Automated Assembly">
           <p>
  -           Underlying the Merlin system is a assembly engine that 
  -           provides support for the deployment of components.  The 
  -           assembly engine takes care of depedency resolution, 
  -           component instantiation, lifecycle processing, and 
  -           component decommissioning.
  +Underlying the Merlin system is a assembly engine that provides support for the deployment
of components.  The assembly engine takes care of dependency resolution, component instantiation,
lifecycle processing, and component decommissioning.
           </p>
         </subsection>
         <subsection name="Lifestyle Management">
           <p>
  -           Merlin provides support for different component instantiation
  -           policies.  These policies are referred to as lifestyles. Examples
  -           of supported lifestyle include 'singleton', 'per-thread', 'pooled'
  -           and 'transient'.
  +Merlin provides support for different component instantiation policies.  These policies
are referred to as lifestyles. Examples of supported lifestyle include 'singleton', 'per-thread',
'pooled' and 'transient'.
           </p>
         </subsection>
         <subsection name="Lifecycle Management">
           <p>
  -           Following instantiation, a component is processed through a 
  -           lifecycle.  Lifecycle processing involves the execution of a 
  -           series of stages such associating a logging channel, applying
  -           a configuration or component parameters, setting the runtime 
  -           context, supplying dependent services, initialization, startup,
  -           shutdown and disposal.  Within the merlin system, lifecycle
  -           stages can be extended or modified through association of other
  -           components that provide lifecycle support.  Merlin distinguishes
  -           these services as deployment dependecies as distinct from classic
  -           runtime dependecies.
  +Following instantiation, a component is processed through a lifecycle.  Lifecycle processing
involves the execution of a series of stages such associating a logging channel, applying
a configuration or component parameters, setting the runtime context, supplying dependent
services, initialization, startup, shutdown and disposal.  Within the Merlin system, lifecycle
stages can be extended or modified through association of other components that provide lifecycle
support.  Merlin distinguishes these services as deployment dependencies as distinct from
classic runtime dependencies.
           </p>
         </subsection>
   
  
  
  
  1.2       +5 -33     avalon-sandbox/merlin/merlin-smp/xdocs/about/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/about/index.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.xml	2 Apr 2003 15:51:52 -0000	1.1
  +++ index.xml	8 Apr 2003 11:19:51 -0000	1.2
  @@ -25,12 +25,7 @@
   
       <subsection name="Service Management Platform (SMP)">
   <p>
  -Merlin System is a service management platform based
  -on an advanced assembly engine.  If focus is to provide support
  -for the encapsulation of a set of components and services
  -within functional blocks.  Blocks enable the separation of
  -components as an implementation solutions, from services
  -established by respective components.
  +Merlin is a service management platform based on an advanced assembly engine.  Its focus
is to provide support for the encapsulation of a set of components and services within functional
blocks.  Blocks enable the separation of components as an implementation solutions from services
established by respective components.
        </p>
   
       </subsection>
  @@ -38,44 +33,21 @@
       <subsection name="Assembly Framework">
   
   <p>
  -The assembly engine is responsible for the management of the
  -the deployment of services provided by a component. 
  +The assembly engine is responsible for the management of the deployment of services provided
by a component. 
   </p>
   
   <p>
  -Components in the framework may have dependencies on services
  -provided by other components, which in turn may have
  -dependencies of their own.  In addition, components can
  -declare (as part of their meta-info) particular lifecycle
  -stages (such as initiation or configuration) and the type
  -of stage provider it needs to handle that stage.  So in
  -effect, components can be deployed with classic runtime
  -dependencies together with deployment dependencies (because
  -deployment stage providers are themselves components that 
  -may have their own deployment and runtime dependencies).
  +Components in the framework may have dependencies on services provided by other components,
which in turn may have dependencies of their own.  In addition, components can declare (as
part of their meta-info) particular lifecycle stages (such as initiation or configuration)
and the type of stage provider it needs to handle that stage.  So in effect, components can
be deployed with classic runtime dependencies together with deployment dependencies (because
deployment stage providers are themselves components that may have their own deployment and
runtime dependencies).
   </p>
   
   <p>
  -Assembly services include ordered deployment and
  -decommissioning, and a range of "lifestyle" handlers (things
  -like thread-safe, per-thread, singleton, transient, or
  -custom policies).  The package includes facilities for:
  -classloader management and cascading repositories for
  -types, templates, service definitions and appliance
  -instances (where an appliance is simply an instantiation of a
  -particular component deployment scenario). 
  +Assembly services include ordered deployment and decommissioning, and a range of "lifestyle"
handlers (things like thread-safe, per-thread, singleton, transient, or custom policies).
 The package includes facilities for: classloader management and cascading repositories for
types, templates, service definitions and appliance instances (where an appliance is simply
an instantiation of a particular component deployment scenario). 
   </p>
       </subsection>
   
       <subsection name="Meta Model">
   <p>
  -The meta model used in Merlin defines the notion of a component type.  A Type
  -defintion contains infromation about deployment and runtime dependecies together
  -with general attributes about the type and the Services the component type can 
  -provide. The Type and Service notions are complimented by a Profile which can be
  -viewed as a template deployment scenario.  Type, Service and Profile descriptions
  -can be packaged in jars files and used as the basic for automating component 
  -assembly and deployment. 
  +The meta model used in Merlin defines the notion of a component type.  A Type definition
contains information about deployment and runtime dependencies together with general attributes
about the type and services the component type can provide. The Type and Service notions are
complimented by a Profile which can be viewed as a template deployment scenario.  Type, Service
and Profile descriptions can be packaged in jars files and used as the basic for automating
component assembly and deployment. 
   </p>
   
       </subsection>
  
  
  
  1.2       +3 -12     avalon-sandbox/merlin/merlin-smp/xdocs/about/purpose.xml
  
  Index: purpose.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/about/purpose.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- purpose.xml	2 Apr 2003 15:51:52 -0000	1.1
  +++ purpose.xml	8 Apr 2003 11:19:51 -0000	1.2
  @@ -14,26 +14,17 @@
       <section name="Purpose">
         <subsection name="Simplification">
           <p>
  -           Merlin aims to simplify the process of managing component
  -           based systems.  It achives this objective through delivery
  -           of functionality supporting automated component assembly 
  -           and deployment.
  +Merlin aims to simplify the process of managing component-based systems.  It achieves this
objective through delivery of functionality supporting automated component assembly and deployment.
           </p>
         </subsection>
         <subsection name="Isolation">
           <p>
  -           Merlin aims to provide a frawork for isolating an application 
  -           implementation from the service that the application provides.
  -           Applications are implemented through component composition. In
  -           turn, applications can be exposed as simple components and 
  -           used by other components in building other applications.
  +Merlin aims to provide a framework for isolating an application implementation from the
service that the application provides. Applications are implemented through component composition.
In turn, applications can be exposed as simple components and used by other components in
building other applications.
           </p>
         </subsection>
         <subsection name="Distribution">
           <p>
  -           A goal of the Merlin project is to provide distribution of 
  -           services established by system to other Merlin systems across
  -           a distributed network environment.
  +A goal of the Merlin project is to provide distribution of services established by system
to other Merlin systems across a distributed network environment.
           </p>
         </subsection>
       </section>
  
  
  
  1.2       +2 -2      avalon-sandbox/merlin/merlin-smp/xdocs/extensions/servlet/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/extensions/servlet/index.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.xml	8 Apr 2003 08:59:19 -0000	1.1
  +++ index.xml	8 Apr 2003 11:19:51 -0000	1.2
  @@ -17,7 +17,7 @@
   
       <subsection name="Development Notes">
   <p>
  -This is an inimial implementation of a Servlet that contains an embedded kernel.  The behaviour
is a function of the block.xml resource resolved via the initialization parameters.  No support
is included for configuration of the kernel and as such the kernel is established relative
to defaults.  This will be enhanced in a leter revision.
  +This is a minimal implementation of a Servlet that contains an embedded kernel.  The behaviour
is a function of the block.xml resource resolved via the initialisation parameters.  No support
is included for configuration of the kernel and as such the kernel is established relative
to defaults.  This will be enhanced in a later revision.
   </p>
   
       </subsection>
  
  
  
  1.2       +3 -22     avalon-sandbox/merlin/merlin-smp/xdocs/merlin/appliance/assembly.xml
  
  Index: assembly.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/merlin/appliance/assembly.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- assembly.xml	2 Apr 2003 21:57:58 -0000	1.1
  +++ assembly.xml	8 Apr 2003 11:19:51 -0000	1.2
  @@ -11,33 +11,14 @@
       <section name="Assembly - Functional Description">
   
   <p>
  -The assembly system is all about the management of the
  -the deployment of services provided by a component.  The
  -package provides support for the declaration of meta
  -information describing component dependencies, and
  -deployment templates.
  +The assembly system is all about the management of the deployment of services provided
by a component.  The package provides support for the declaration of meta-info describing
component dependencies, and deployment templates.
   </p>
   
   <p>
  -Components in the framework may have dependencies on services
  -provided by other components, which in turn may have
  -dependencies of their own.  In addition, components can
  -declare (as part of their meta-info) particular lifecycle
  -stages (such as initiation or configuration) and the type
  -of stage provider it needs to handle that stage.  So in
  -effect, components can be deployed with classic runtime
  -dependencies together with deployment dependencies (because
  -deployment stage providers are themselves components).
  +Components in the framework may have dependencies on services provided by other components,
which in turn may have dependencies of their own.  In addition, components can declare (as
part of their meta-info) particular lifecycle stages (such as initiation or configuration)
and the type of stage provider it needs to handle that stage.  So in effect, components can
be deployed with classic runtime dependencies together with deployment dependencies (because
deployment stage providers are themselves components).
   </p>
   <p>
  -Assembly services include ordered deployment and
  -decommissioning, a range of "lifestyle" handlers (things
  -like thread-safe, per-thread, singleton, transient, or
  -custom policies).  The package includes facilities for:
  -classloader management and cascading repositories for
  -types, templates, service definitions and appliance
  -instances (appliance is simply an instantiation of a
  -particular component deployment scenario). 
  +Assembly services include ordered deployment and decommissioning, a range of "lifestyle"
handlers (things like thread-safe, per-thread, singleton, transient, or custom policies).
 The package includes facilities for: classloader management and cascading repositories for
types, templates, service definitions and appliance instances (appliance is simply an instantiation
of a particular component deployment scenario). 
   </p>
       </section>
     </body>
  
  
  
  1.2       +2 -2      avalon-sandbox/merlin/merlin-smp/xdocs/merlin/appliance/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/merlin/appliance/index.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.xml	2 Apr 2003 21:57:58 -0000	1.1
  +++ index.xml	8 Apr 2003 11:19:51 -0000	1.2
  @@ -11,12 +11,12 @@
       <section name="Appliance">
         <subsection name="Overview">
           <p>
  -        An appliance is the internal handler of a component.  It is responsible for component
deployment and decommissioning.  An appliance can be view as an instance of a unique named
deployment scenario where a deployment scenario is the result of combining a particular component
type with deployment meta-data (configuration, context directives, etc.).
  +An appliance is the internal handler of a component.  It is responsible for component deployment
and decommissioning.  An appliance can be view as an instance of a unique named deployment
scenario where a deployment scenario is the result of combining a particular component type
with deployment meta-data (configuration, context directives, etc.).
           </p>
         </subsection>
         <subsection name="Components">
           <p>
  -        An component is an instantiated java.lang.Object managed by an Appliance.  A component
is characterised by deployment and runtime dependecies which are mananged by an appliance
in response to service requests. A component typically exposes services (public interfaces)
through implementation or other means.  In addition a component may declare runtime dependencies
on service provided by other components.  Wiring together provider and consumer components
to fulfill deployment and runtime dependencies is referred to as component assembly.
  +A component is an instantiated java.lang.Object managed by an Appliance.  A component is
characterised by deployment and runtime dependencies which are managed by an appliance in
response to service requests. A component typically exposes services (public interfaces) through
implementation or other means.  In addition a component may declare runtime dependencies on
service provided by other components.  Wiring together provider and consumer components to
fulfil deployment and runtime dependencies is referred to as component assembly.
           </p>
         </subsection>
       </section>
  
  
  
  1.2       +2 -2      avalon-sandbox/merlin/merlin-smp/xdocs/merlin/appliance/lifestyle.xml
  
  Index: lifestyle.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/merlin/appliance/lifestyle.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- lifestyle.xml	2 Apr 2003 21:57:58 -0000	1.1
  +++ lifestyle.xml	8 Apr 2003 11:19:51 -0000	1.2
  @@ -9,7 +9,7 @@
   
       <section name="Lifestyle Management">
   <p>
  -A lifestyle is a term that reflects a component implementation approach.  Four basic lifestyle
strategies are included in the Assembly API - thse include the singleton, per-thread, pooled,
and transient strategies.  More information about these strategies is included in the following
table:
  +A lifestyle is a term that reflects a component implementation approach.  Four basic lifestyle
strategies are included in the Assembly API - these include the singleton, per-thread, pooled,
and transient strategies.  More information about these strategies is included in the following
table:
   </p>
       
       <subsection name="Strategies">
  
  
  
  1.4       +13 -16    avalon-sandbox/merlin/merlin-smp/xdocs/merlin/block/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/merlin/block/index.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- index.xml	3 Apr 2003 14:39:52 -0000	1.3
  +++ index.xml	8 Apr 2003 11:19:51 -0000	1.4
  @@ -13,32 +13,29 @@
         <subsection name="Overview">
   
         <p>
  -      A block is a specialization of an <a href="../appliance/index.html">Appliance</a>.
A block manages a container (a type of component).  In addition, a block exposes services
derived from the set of appliances that are managed by it's container.  As such, a block can
be view as a composite component.  A block may be contained within other blocks.
  +A block is a specialisation of an <a href="../appliance/index.html">Appliance</a>.
A block manages a container (a type of component).  In addition, a block exposes services
derived from the set of appliances that are managed by its container.  As such, a block can
be view as a composite component.  A block may be contained within other blocks.
         </p>
         <p>
  -      A container manages a set of components declared within the containment scope.  As
such, a container represents a logical and structural partition within a containment heirachy.
 Each container is associated with a classloader.  The classloader parent is the classloader
of the parent container.  As such, a container (and component within the container) have access
to the services defined within the immediate container and all parent containers. 
  +A container manages a set of components declared within the containment scope.  As such,
a container represents a logical and structural partition within a containment hierarchy.
 Each container is associated with a classloader.  The classloader parent is the classloader
of the parent container.  As such, a container (and component within the container) have access
to the services defined within the immediate container and all parent containers. 
         </p>
   
         </subsection>
         <subsection name="Cascading Containers">
   
  -      <p>The Merlin system provides support for <strong>cascading containers</strong>.
This model
  -      enables component assemblers to (among other things) associate jar files under a
protected
  -      block scope where each block is associated with its own classloader.  Each block
manages 
  -      a single container.  A container manages multiple components.</p>
  +      <p>
  +The Merlin system provides support for <strong>cascading containers</strong>.
This model enables component assemblers to (among other things) associate jar files under
a protected block scope where each block is associated with its own classloader.  Each block
manages a single container.  A container manages multiple components.
  +      </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.</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.
  +      </p>
   
         </subsection>
         <subsection name="Block Model">
   
  -      <p>A new block is defined by the &lt;block&gt; element. The element
is the definition of a
  -      block, its classpath, and the components it is responsible for managing.
  -      Blocks are declared programmatically or via an XML description as shown below:</p>
  +      <p>
  +A new block is defined by the &lt;block&gt; element. The element is the definition
of a block, its classpath, and the components it is responsible for managing. Blocks are declared
programmatically or via an XML description as shown below:
  +      </p>
   
         <p><em>Minimilist block definition:</em></p>
   <source><![CDATA[
  
  
  
  1.4       +2 -9      avalon-sandbox/merlin/merlin-smp/xdocs/merlin/block/packaging.xml
  
  Index: packaging.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/merlin/block/packaging.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- packaging.xml	3 Apr 2003 14:39:52 -0000	1.3
  +++ packaging.xml	8 Apr 2003 11:19:51 -0000	1.4
  @@ -11,17 +11,10 @@
       <section name="Block">
         <subsection name="Block Packaging">
           <p>
  -          During the scanning phase the Merlin Kernel looks though the 
  -          directory of a jar file for resources with the .xinfo, .xtype, 
  -          .xservice, .xconfig and .xprofile extensions.  These extensions
  -          declare to Merlin th available types (.xinf and .xtype), services
  -          (.xservice), deault type level confiurations (.xconfig), and packaged
  -          deployment profile templates (.xprofile).
  +During the scanning phase the Merlin Kernel looks though the directory of a jar file for
resources with the .xinfo, .xtype, .xservice, .xconfig and .xprofile extensions.  These extensions
declare to Merlin the available types (.xinfo and .xtype), services (.xservice), default type
level configurations(.xconfig), and packaged deployment profile templates (.xprofile).
           </p>
           <p>
  -          In addition, Merlin will attempt to read a block directive under the 
  -          jar resource pathof BLOCK-INF/block.xml.  If a resource exists, the 
  -          supplied jar file wil be consider as a block.
  +In addition, Merlin will attempt to read a block directive under the jar resource path
of BLOCK-INF/block.xml.  If a resource exists, the supplied jar file will be consider as a
block.
           </p>
         </subsection>
       </section>
  
  
  
  1.3       +6 -14     avalon-sandbox/merlin/merlin-smp/xdocs/merlin/kernel/cli.xml
  
  Index: cli.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/merlin/kernel/cli.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- cli.xml	3 Apr 2003 14:39:52 -0000	1.2
  +++ cli.xml	8 Apr 2003 11:19:52 -0000	1.3
  @@ -13,28 +13,20 @@
       <section name="Merlin CLI (Command Line Interface)">
         <subsection name="Overview">
         <p>
  -        Merlin CLI is the command line interface to the merlin system.
  -        It provides suppprt for the declaration of the root block
  -        directive, a working home directory, a kernel directive, 
  -        and other parameters qualifying debug output and language 
  -        policy.
  +Merlin CLI is the command line interface to the Merlin system. It provides support for
the declaration of the root block directive, a working home directory, a kernel directive,
and other parameters qualifying debug output and language policy.
         </p>
         <p>
  -        The prime objective the Merlin CLI is to lauch a root block 
  -        descriptor and facilitate the deployment of the block and as a 
  -        consequence, the deployment of subsidiary blocks, containers and
  -        components.
  +The prime objective the Merlin CLI is to launch a root block descriptor and facilitate
the deployment of the block and as a consequence, the deployment of subsidiary blocks, containers
and components.
         </p>
         </subsection>
         <subsection name="Command Line">
           <p>
  -          The Merlin CLI takes a [block] argument as it's primary 
  -          argument.  The block may be a block XML file or a jar file
  -          containing a block directive.
  +The Merlin CLI takes a [block] filename as it's primary argument.  The block may be a block
XML file or a jar file containing a block directive.
           </p>
           <p>
  -          <i>Example of block deployment based on a supplied block
  -          directive.</i>
  +          <i>
  +Example of block deployment based on a supplied block directive.
  +          </i>
           </p>
   <source><![CDATA[
    $ merlin -help
  
  
  
  1.2       +9 -11     avalon-sandbox/merlin/merlin-smp/xdocs/merlin/kernel/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/merlin/kernel/index.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.xml	2 Apr 2003 15:51:57 -0000	1.1
  +++ index.xml	8 Apr 2003 11:19:52 -0000	1.2
  @@ -13,19 +13,17 @@
   
       <section name="Merlin Kernel">
   
  -    <p>Merlin separates the concepts of <strong>Kernel</strong> and <strong>Container</strong>.
  -    A kernel manages <em>resources</em> (Objects) whereas a container manages
<em>services</em>. 
  -    Merlin provides a default kernel that manages a container hierarchy:
  -    <a href="../../apidocs/org/apache/avalon/merlin/kernel/impl/DefaultKernel.html">DefaultKernel</a>.
  -    It handles overall management, including startup, shutdown, extension management, and
other
  -    system-wide tasks.</p>
  +    <p>
  +Merlin separates the concepts of <strong>Kernel</strong> and <strong>Container</strong>.
A kernel manages <em>resources</em> (Objects) whereas a container manages <em>services</em>.
Merlin provides a default kernel that manages a container hierarchy: <a href="../../apidocs/org/apache/avalon/merlin/kernel/impl/DefaultKernel.html">DefaultKernel</a>.
It handles overall management, including startup, shutdown, extension management, and other
system-wide tasks.
  +    </p>
   
  -    <p>The kernel provides a set of bootstrap services (like a logging
  -    service) and context entries to the (root) container it is managing. It subsequently
  -    publishes established entries and services
  -    (derived from container deployment) towards kernel clients.</p>
  +    <p>
  +The kernel provides a set of bootstrap services (like a logging service) and context entries
to the (root) container it is managing. It subsequently publishes established entries and
services (derived from container deployment) towards kernel clients.
  +    </p>
   
  -    <p><em>Kernel to Container conceptual relationship:</em></p>
  +    <p><em>
  +Kernel to Container conceptual relationship:
  +    </em></p>
   
       <img src="./../../images/overview.gif" />
   
  
  
  
  1.3       +1 -2      avalon-sandbox/merlin/merlin-smp/xdocs/merlin/kernel/nt.xml
  
  Index: nt.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/merlin/kernel/nt.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- nt.xml	3 Apr 2003 14:39:52 -0000	1.2
  +++ nt.xml	8 Apr 2003 11:19:52 -0000	1.3
  @@ -12,8 +12,7 @@
     <body>
       <section name="Merlin NT Service">
         <p>
  -      The Merlin installation includes support for the running of 
  -      a Merlin Kernel as an Windows(TM) NT4 Service.
  +The Merlin installation includes support for the running of a Merlin Kernel as an Windows(TM)
NT4 Service.
         </p>
         <p>
           <img src="../../images/service.gif"/>
  
  
  
  1.2       +3 -3      avalon-sandbox/merlin/merlin-smp/xdocs/starting/examples/afs/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/avalon-sandbox/merlin/merlin-smp/xdocs/starting/examples/afs/index.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.xml	6 Apr 2003 19:31:25 -0000	1.1
  +++ index.xml	8 Apr 2003 11:19:52 -0000	1.2
  @@ -22,10 +22,10 @@
               <td><a href="simple/index.html">Simple Bank</a></td>
               <td>
                 The Simple Bank implementation aims to establish a minimal 
  -              implementation - unsecure, simplistic, but funtional. The 
  -              example demonstrates a bank component and non-component artifacts
  +              implementation - unsecured, simplistic, but functional. The 
  +              example demonstrates a bank component and non-component artefacts
                 (such as an account) together with test cases that demonstrate 
  -              account creation, depositing and withdrawl of funds, serialization
  +              account creation, depositing and withdrawal of funds, serialization
                 of the state of the bank, and account closure.
               </td>
             </tr>
  
  
  

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


Mime
View raw message