avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hamm...@apache.org
Subject cvs commit: jakarta-avalon-phoenix/src/documentation/content/mx index.xml structure.xml xdoctags.xml
Date Mon, 02 Dec 2002 08:07:34 GMT
hammant     2002/12/02 00:07:34

  Modified:    src/documentation/content/assemblers index.xml
               src/documentation/content/bdg
                        making-phoenix-compatible-comps.xml
                        what-is-an-application-listener.xml
               src/documentation/content features.xml
                        for-developers-alternate-kernel.xml
                        getting-started.xml guide-administrator.xml
                        guide-architecture.xml index.xml install.xml
               src/documentation/content/mx index.xml structure.xml
                        xdoctags.xml
  Log:
  Typos fixed by Adam Murdoch
  
  Revision  Changes    Path
  1.2       +1 -1      jakarta-avalon-phoenix/src/documentation/content/assemblers/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/assemblers/index.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.xml	18 Nov 2002 14:18:49 -0000	1.1
  +++ index.xml	2 Dec 2002 08:07:34 -0000	1.2
  @@ -21,7 +21,7 @@
           <section><title>Organization</title>
               <p>
                 The information is organized into sections detailing a specifc aspect of
  -              assembling ServerApplications.
  +              assembling Server Applications.
               </p>
           </section>
           <section><title>Contents</title>
  
  
  
  1.3       +11 -11    jakarta-avalon-phoenix/src/documentation/content/bdg/making-phoenix-compatible-comps.xml
  
  Index: making-phoenix-compatible-comps.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/bdg/making-phoenix-compatible-comps.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- making-phoenix-compatible-comps.xml	18 Nov 2002 23:19:36 -0000	1.2
  +++ making-phoenix-compatible-comps.xml	2 Dec 2002 08:07:34 -0000	1.3
  @@ -10,7 +10,7 @@
         <p>
         Quite often reusable components are made elsewhere.  Apache has a number
         of places where this activity is going on.  While we get it right most of
  -      the time, some components developer elsewhere are harder to use in Phoenix
  +      the time, some components developed elsewhere are harder to use in Phoenix.
         </p>
       </section>
       <section><title>Things to remember</title>
  @@ -36,18 +36,18 @@
            <p>The IoC pattern is described <link href="http://jakarta.apache.org/avalon/framework/inversion-of-control.html">
            here</link>.  This means for Phoenix avoiding static concepts including
loggers.</p>
         </section>
  -      <section><title>Sepearation of interface and implementation</title>
  +      <section><title>Separation of interface and implementation</title>
           <p>
  -         The separation of interface/impl pattern is described <link href="http://jakarta.apache.org/avalon/framework/separation-of-interface-and-implementation.html">here</link>.
  -         For Phoenix is means we can (if done completely) mount the implementation jar
in place where hosted client compoennts (beans, servlets etc) can use the API, bit not see
the implementation.  We can also reimplement or wrap
  +         The separation of interface/implementation pattern is described <link href="http://jakarta.apache.org/avalon/framework/separation-of-interface-and-implementation.html">here</link>.
  +         For Phoenix this means we can (if done completely) mount the implementation jar
in place where hosted client components (beans, servlets etc) can use the API, but not see
the implementation.  We can also reimplement or wrap
            bits of the implementation.  For example we could write a pluggable implementation
that could, for a certain API
  -         journal some methods, but still delegate to the real impl.  Which pluggable impl
is used by Phoenix when it
  +         journal some methods, but still delegate to the real implementation.  Which pluggable
implementation is used by Phoenix when it
            boots is determined in assembly.xml of course.
           </p>
         </section>
         <section><title>Opening up the API</title>
           <p>
  -         Given that you have divided into interface and impl, there are probably plenty
of methods you
  +         Given that you have divided into interface and implementation, there are probably
plenty of methods you
            can put method in the interface you never though might be used.  For example if
you are making JDBC
            compliant relational database, and it is a bean, you could easily think that the
only use would be
            clients via JDBC over sockets.  Well, given that Phoenix can now mount the RDBMS
block, it might want
  @@ -61,9 +61,9 @@
           </p>
         </section>
       </section>
  -    <section><title>Example compatible comp</title>
  +    <section><title>Example compatible component</title>
       <p>
  -      Below are an interface and implemmentation that are suitably separated, are beanlike
and is in accordance
  +      Below are an interface and implementation that are suitably separated, are beanlike
and is in accordance
         with the IoC pattern...</p>
   <source>
   package examplecomp;
  @@ -111,7 +111,7 @@
       }
   }
   </source>
  -      <p>When we are trying to run this in phoeinix we might have this wrapper:</p>
  +      <p>When we are trying to run this in phoenix we might have this wrapper:</p>
   <source>
   package examplecomp.block;
   public class WebServerBlock
  @@ -152,8 +152,8 @@
       }
   }
   </source>
  -      <p>This basically shows the impl wrapped and taking its configuration from
the config.xml
  -      that phonix prefers from configuration.  The the developer wanted they could ignore
  +      <p>This basically shows the implementation wrapped and taking its configuration
from the config.xml
  +      that phoenix prefers from configuration.  If the developer wanted they could ignore
         that place of configuration and use their own config files.  If the WebServer block
were
         being reused by another Phoenix block (say an EJB server), it might be like so:</p>
   <source>
  
  
  
  1.2       +2 -2      jakarta-avalon-phoenix/src/documentation/content/bdg/what-is-an-application-listener.xml
  
  Index: what-is-an-application-listener.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/bdg/what-is-an-application-listener.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- what-is-an-application-listener.xml	18 Nov 2002 14:19:02 -0000	1.1
  +++ what-is-an-application-listener.xml	2 Dec 2002 08:07:34 -0000	1.2
  @@ -11,14 +11,14 @@
           This is very similar to <em>BlockListener</em> in that it is notified
           during lifecycle of blocks and application.  In Java terms the
           <em>ApplicationListener</em> interface extends <em>BlockListener</em>
  -        so it is always informd of both types of events
  +        so it is always informed of both types of events.
         </p>
       </section>
       <section><title>Events notified</title>
         <p>
           ApplicationListener components are created before any Blocks are
           created in an Application. They receive notifications before and
  -        after the Applictaion is started and stopped.
  +        after the Application is started and stopped.
         </p>
       </section>
       <section><title>How to make a block listener</title>
  
  
  
  1.2       +2 -2      jakarta-avalon-phoenix/src/documentation/content/features.xml
  
  Index: features.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/features.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- features.xml	18 Nov 2002 14:18:18 -0000	1.1
  +++ features.xml	2 Dec 2002 08:07:34 -0000	1.2
  @@ -18,14 +18,14 @@
       <ul>
           <li>Customise behaviour quickly</li>
           <li>Plug in extra functionality effortlessly</li>
  -        <li>remove unneeded functionality for a small footprint</li>
  +        <li>Remove unneeded functionality for a small footprint</li>
       </ul>
   </section>
   
   <section><title>Flexible environment</title>
       <p>Phoenix has native support for use in the following environments:</p>
       <ul>
  -        <li>command-line stand-alone program</li>
  +        <li>Command-line stand-alone program</li>
           <li>Unix daemon</li>
           <li>Embedded in other programs (including servlet engines)</li>
       </ul>
  
  
  
  1.3       +1 -1      jakarta-avalon-phoenix/src/documentation/content/for-developers-alternate-kernel.xml
  
  Index: for-developers-alternate-kernel.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/for-developers-alternate-kernel.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- for-developers-alternate-kernel.xml	30 Nov 2002 08:43:42 -0000	1.2
  +++ for-developers-alternate-kernel.xml	2 Dec 2002 08:07:34 -0000	1.3
  @@ -15,7 +15,7 @@
       </section>
       <section><title>Beanshell enabled kernel</title>
         <p>
  -        This allows pretty much any anything to be done to applications 
  +        This allows pretty much anything to be done to applications 
           and blocks once started.  As such it is not suitable for live 
           deployment as it could be considered a bit of a hackers tool.
         </p>
  
  
  
  1.4       +1 -1      jakarta-avalon-phoenix/src/documentation/content/getting-started.xml
  
  Index: getting-started.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/getting-started.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- getting-started.xml	18 Nov 2002 23:48:53 -0000	1.3
  +++ getting-started.xml	2 Dec 2002 08:07:34 -0000	1.4
  @@ -55,7 +55,7 @@
       has compiled correctly by running the HelloWorld demo Service Application.
   </p>
   <p>
  -    Firstly you will need to get the demo-helloword.sar file and drop it into
  +    Firstly you will need to get the demo-helloworld.sar file and drop it into
       the apps directory of Phoenix.  Currently it needs to be built from CVS -
       <link href="http://cvs.apache.org/viewcvs/jakarta-avalon-apps/demo/">
       http://cvs.apache.org/viewcvs/jakarta-avalon-apps/demo/</link>.
  
  
  
  1.2       +1 -1      jakarta-avalon-phoenix/src/documentation/content/guide-administrator.xml
  
  Index: guide-administrator.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/guide-administrator.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- guide-administrator.xml	18 Nov 2002 14:18:18 -0000	1.1
  +++ guide-administrator.xml	2 Dec 2002 08:07:34 -0000	1.2
  @@ -193,7 +193,7 @@
                   documentation</link>.  Phoenix uses the JRMP RMI Adaptor.
                 </p>
                 <p>
  -                Ensure that the MX4J RMI Adaptor is enabled in kernal.xml
  +                Ensure that the MX4J RMI Adaptor is enabled in kernel.xml
                 </p>
   <source>
           &lt;component role="org.apache.avalon.phoenix.interfaces.SystemManager"
  
  
  
  1.2       +3 -3      jakarta-avalon-phoenix/src/documentation/content/guide-architecture.xml
  
  Index: guide-architecture.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/guide-architecture.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- guide-architecture.xml	18 Nov 2002 14:18:18 -0000	1.1
  +++ guide-architecture.xml	2 Dec 2002 08:07:34 -0000	1.2
  @@ -47,10 +47,10 @@
               </section>
               <section><title>Packaging in terms of block jar files</title>
                   <p>
  -                  The server application is entirely contained withing one "sar" file.
 Sar is "Server ARchive".
  +                  The server application is entirely contained within one "sar" file. 
Sar is "Server ARchive".
                     Each block is a jar file.  The dependant libraries are regular jars (placed
  -                  within a directory "lib" insde the sar file).  The Assembly and configuration
instructions
  -                  are in xml form and contained within a "conf" directory inside the sar
file.
  +                  within a directory "SAR-INF/lib" insde the sar file).  The Assembly and
configuration instructions
  +                  are in xml form and contained within a "SAR-INF" directory inside the
sar file.
                   </p>
                   <figure src="images/phoenix-app-blockjars.jpg" alt="Phoenix application
in block jar view"/>
               </section>
  
  
  
  1.3       +1 -1      jakarta-avalon-phoenix/src/documentation/content/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/index.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- index.xml	22 Nov 2002 22:22:13 -0000	1.2
  +++ index.xml	2 Dec 2002 08:07:34 -0000	1.3
  @@ -21,7 +21,7 @@
       <section><title>Documentation is coming</title>
         <p>
           Some of the information on this site is currently a bit out of date. We are
  -    working hard to fix this. If you come across any incosistencies or have a
  +    working hard to fix this. If you come across any inconsistencies or have a
       problem, please don't hesitate to contact us through the mailing list. Thank
       you.
         </p>
  
  
  
  1.2       +1 -1      jakarta-avalon-phoenix/src/documentation/content/install.xml
  
  Index: install.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/install.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- install.xml	18 Nov 2002 14:18:18 -0000	1.1
  +++ install.xml	2 Dec 2002 08:07:34 -0000	1.2
  @@ -16,7 +16,7 @@
   </p>
   
   <p>
  -    Everything required to run Phoenix and develope Phoenix based products comes with the
  +    Everything required to run Phoenix and develop Phoenix based products comes with the
       <link href="http://jakarta.apache.org/builds/avalon/release">distribution</link>.
If
       you wish to help develop Avalon/Phoenix then it is recomended that you obtain the full
       source tree from <link href="http://jakarta.apache.org/getinvolved/cvsindex.html">CVS</link>
  
  
  
  1.2       +3 -3      jakarta-avalon-phoenix/src/documentation/content/mx/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/mx/index.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.xml	18 Nov 2002 14:19:13 -0000	1.1
  +++ index.xml	2 Dec 2002 08:07:34 -0000	1.2
  @@ -17,7 +17,7 @@
           <section><title>Overview</title>
               <p>
                   Management in Phoenix is divided into two distinct areas.  The first 
  -                area is the the management metadata.  This information about which
  +                area is the the management metadata.  This is information about which
                   applications, blocks and
                   components should be managed, the operations and attributes
                   to expose, and descriptions for each these to help guide the user.
  @@ -29,7 +29,7 @@
               <p>
                   The second area is the Phoenix component that uses the
                   MXINFO files to generate a user interface through which Phoenix
  -                and its applications are interacted with.  It is anticated that a number
  +                and its applications are interacted with.  It is anticipated that a number
                   of such interfaces will be developed.  The current implementation
                   of the management component uses the MXINFO files to generate
                   ModelMBeans that are then registered and exposed through a slightly 
  @@ -52,7 +52,7 @@
                   This section provides a conceptual overview of the elements that
                   are used to represent management information within Phoenix.
                   An understanding of these elements and their relationships is 
  -                essential for all users are the management functionality.
  +                essential for all users of the management functionality.
               </p>
               <p>
                   <link href="structure.html">Structure</link>
  
  
  
  1.3       +5 -5      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.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- structure.xml	18 Nov 2002 23:18:08 -0000	1.2
  +++ structure.xml	2 Dec 2002 08:07:34 -0000	1.3
  @@ -8,12 +8,12 @@
     <body>
       <section><title>Introduction</title>
         <p>
  -        Phoenix Management seperates the information on what should be managed
  +        Phoenix Management separates the information on what should be managed
           from the implementation of the management agent.  In order to maintain
  -        this seperation, yet still allow the management interface to be rich
  +        this separation, yet still allow the management interface to be rich
           and structured enough to be useful, it is necessary to impose an organizing
           strucuture on the management metadata.  This structure will be common
  -        across all management interfaces, althought the specifics of how it is
  +        across all management interfaces, although the specifics of how it is
           exposed is up to the implementor.
         </p>
       </section>
  @@ -31,7 +31,7 @@
             sub-Contexts.
           </p>
           <p>
  -          This nested structure of Contexts is the principle
  +          This nested structure of Contexts is the principal
             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
  @@ -95,7 +95,7 @@
         </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
  +        separated from the  management agent, while at the same time providing enough definition
           to keep a shared conceptual view between the two areas.
         </p>
       </section>
  
  
  
  1.2       +27 -27    jakarta-avalon-phoenix/src/documentation/content/mx/xdoctags.xml
  
  Index: xdoctags.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/documentation/content/mx/xdoctags.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- xdoctags.xml	18 Nov 2002 14:19:13 -0000	1.1
  +++ xdoctags.xml	2 Dec 2002 08:07:34 -0000	1.2
  @@ -108,14 +108,14 @@
             Example:
           </p>
           <source>
  -    /**
  -     * Gets the list of applications running in the container
  -     *
  -     * @phoenix:mx-attribute
  -     *
  -     * @return applicationNames The array of application names
  -     */
  -    String[] getApplicationNames();
  +/**
  + * Gets the list of applications running in the container
  + *
  + * @phoenix:mx-attribute
  + *
  + * @return applicationNames The array of application names
  + */
  +String[] getApplicationNames();
           </source>
         </section>
         <section><title>phoenix:mx-operation</title>
  @@ -150,14 +150,14 @@
             Example:
           </p>
           <source>
  -    /**
  -     * Removes the application from the container
  -     *
  -     * @phoenix:mx-operation
  -     *
  -     * @param name the name of application to remove
  -     */
  -    void removeApplication( String name )
  +/**
  + * Removes the application from the container
  + *
  + * @phoenix:mx-operation
  + *
  + * @param name the name of application to remove
  + */
  +void removeApplication( String name )
           </source>
         </section>
         <section><title>phoenix:mx-description</title>
  @@ -193,16 +193,16 @@
             Example:
           </p>
           <source>
  -    /**
  -     * Retrieve a string identifying version of server.
  -     * Usually looks like "v4.0.1a".
  -     *
  -     * @phoenix:mx-attribute
  -     * @phoenix:mx-description Retrieve a string identifying version of server.
  -     *
  -     * @return version string of server.
  -     */
  -    String getVersion();
  +/**
  + * Retrieve a string identifying version of server.
  + * Usually looks like "v4.0.1a".
  + *
  + * @phoenix:mx-attribute
  + * @phoenix:mx-description Retrieve a string identifying version of server.
  + *
  + * @return version string of server.
  + */
  +String getVersion();
           </source>
         </section>
         <section><title>phoenix:mx-proxy</title>
  @@ -218,7 +218,7 @@
               <td>
                 The proxy tag is used to indicate that a proxy class should be used
                 to manage some aspect(s) of this object.  At runtime, the management
  -              system will instantiate in instance of the proxy class passing in
  +              system will instantiate an instance of the proxy class passing in
                 a reference to the managed object in the constructor.  Management
                 calls are then made on the proxy instead of the managed object.
               </td>
  
  
  

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