avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dona...@apache.org
Subject cvs commit: jakarta-avalon-phoenix/src/documentation/content/mx structure.xml
Date Mon, 18 Nov 2002 23:18:08 GMT
donaldp     2002/11/18 15:18:08

  Modified:    src/documentation/content/mx structure.xml
  Log:
  Make xml validate
  
  Revision  Changes    Path
  1.2       +32 -32    jakarta-avalon-phoenix/src/documentation/content/mx/structure.xml
  
  Index: structure.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/mx/structure.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- structure.xml	18 Nov 2002 14:19:13 -0000	1.1
  +++ structure.xml	18 Nov 2002 23:18:08 -0000	1.2
  @@ -3,7 +3,7 @@
   <document>
     <header>
       <title>Management Guide - Organizing Structure</title>
  -    
  +
     <authors><person name="Huw Roberts" email="huw@apache.org"/></authors></header>
     <body>
       <section><title>Introduction</title>
  @@ -19,7 +19,7 @@
       </section>
       <section><title>Elements</title>
         <p>
  -        Management information is stored in a structured format that contains both a 
  +        Management information is stored in a structured format that contains both a
           functional definition of the actions (what can be done) and descriptive information
           about the actions (to help guide the user).  It is composed of the following elements:
         </p>
  @@ -28,26 +28,26 @@
             In Phoenix, each managed object belongs to a single Context
             The Context contains a list of managed components called Targets.  In
             addition to the list of Targets, a Context can also have zero or more
  -          sub-Contexts.  
  +          sub-Contexts.
           </p>
           <p>
             This nested structure of Contexts is the principle
  -          organizing element for management data, and is the bridge between 
  -          the management code embedded in Phoenix and the implementation of the 
  +          organizing element for management data, and is the bridge between
  +          the management code embedded in Phoenix and the implementation of the
             management component.  It is represented by the
  -          <pre>org.apache.avalon.phoenix.interfaces.SystemManager</pre>
  +          <code>org.apache.avalon.phoenix.interfaces.SystemManager</code>
             interface.
           </p>
         </section>
         <section><title>Target</title>
           <p>
  -          A target is a manageable object.  Examples of Targets in Phoenix include the

  +          A target is a manageable object.  Examples of Targets in Phoenix include the
             components, the applications and the blocks.  Each target has one or more topics.
       </p>
         </section>
         <section><title>Topic</title>
           <p>
  -          A topic is a logical grouping of attributes that can be get and/or set on the
Target and a 
  +          A topic is a logical grouping of attributes that can be get and/or set on the
Target and a
             group of operations that can be called on it.  It is intended that Topics group
together
             a particular aspect of Targets manageability.
           </p>
  @@ -58,30 +58,30 @@
       This diagram illustrates how this might be presented in a management GUI:
         </p>
         <source>
  -Phoenix 
  - | 
  - +--Components 
  - |   +-- Kernel 
  - |   +-- Deployer 
  - |   +-- etc. 
  - | 
  - +--Applications 
  -     +--Hello World 
  +Phoenix
  + |
  + +--Components
  + |   +-- Kernel
  + |   +-- Deployer
  + |   +-- etc.
  + |
  + +--Applications
  +     +--Hello World
        |    +-- Blocks
  -     |          +-- Block 1 
  -     |          +-- Block 2 
  -     | 
  -     +-- Ftp Server 
  +     |          +-- Block 1
  +     |          +-- Block 2
  +     |
  +     +-- Ftp Server
             +-- Blocks
  -                +-- Block 1 
  -                +-- Block 2 
  +                +-- Block 1
  +                +-- Block 2
         </source>
         <p>
  -        In this example Phoenix, Components and Blocks are Contexts.  Kernel, Deployer,
Hello World, Block 1, etc are Targets.  Each Target will then have one or more Topics.  Topics
might be Logging, Lifecycle, Deployer, etc.  
  +        In this example Phoenix, Components and Blocks are Contexts.  Kernel, Deployer,
Hello World, Block 1, etc are Targets.  Each Target will then have one or more Topics.  Topics
might be Logging, Lifecycle, Deployer, etc.
         </p>
         <p>
  -        In a jmx environment each topic would most likely be exported as its own mbean

  -        (so in the above example the jmx name would be 'Instance=Phoenix,Application=Hello_World,Block=Block_2,Topic=Logger'.
 
  +        In a jmx environment each topic would most likely be exported as its own mbean
  +        (so in the above example the jmx name would be 'Instance=Phoenix,Application=Hello_World,Block=Block_2,Topic=Logger'.
         </p>
         <p>
           In a swing environment each topic might have its own tab.
  @@ -94,17 +94,17 @@
   phoenix-mx.describe( ""Phoenix/Applications/Hello World/Logging/LogLevel" );
         </source>
         <p>
  -        Again, the point behind the 'Organizing Structure' is to keep the management specification

  -        seperated from the  management agent, while at the same time providing enough definition

  +        Again, the point behind the 'Organizing Structure' is to keep the management specification
  +        seperated from the  management agent, while at the same time providing enough definition
           to keep a shared conceptual view between the two areas.
         </p>
       </section>
       <section><title>Management Proxies</title>
         <p>
  -        There is one remaining concept to cover, the proxy.  It is a class that can be
used 
  -        to wrap access to the underlying target.  Posible uses include the mapping of data

  -        types to a more friendly type, (eg. from Date to String and back), cleaning up
method names, 
  -        providing backwards compatibility with older versions, and exposing methods 
  +        There is one remaining concept to cover, the proxy.  It is a class that can be
used
  +        to wrap access to the underlying target.  Posible uses include the mapping of data
  +        types to a more friendly type, (eg. from Date to String and back), cleaning up
method names,
  +        providing backwards compatibility with older versions, and exposing methods
           missing from the target class, but available to it via a reference.
         </p>
       </section>
  
  
  

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