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/xdocs for-developers-todo.xml guide-administrator.xml guide-architecture.xml guide-block-developers-making-phoenix-compatible-comps.xml guide-deployers.xml index.xml reference-blockinfo-specification.xml
Date Tue, 21 May 2002 12:17:28 GMT
donaldp     02/05/21 05:17:28

  Modified:    src/xdocs Tag: ANAKIA_DOCS for-developers-todo.xml
                        guide-administrator.xml guide-architecture.xml
                        guide-block-developers-making-phoenix-compatible-comps.xml
                        guide-deployers.xml index.xml
                        reference-blockinfo-specification.xml
  Log:
  s2 --> subsection.
  
  Revision  Changes    Path
  No                   revision
  
  
  No                   revision
  
  
  1.1.2.2   +46 -46    jakarta-avalon-phoenix/src/xdocs/for-developers-todo.xml
  
  Index: for-developers-todo.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/for-developers-todo.xml,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- for-developers-todo.xml	21 May 2002 11:58:19 -0000	1.1.2.1
  +++ for-developers-todo.xml	21 May 2002 12:17:28 -0000	1.1.2.2
  @@ -61,14 +61,14 @@
   
   <section name="Wish List">
   
  -    <s2 title="Separate and Antify Validation code">
  +    <subsection title="Separate and Antify Validation code">
         <p>
         Refactor block validation code. Write an Ant taks that uses this
         and validates the block jar files and another task that validates the
         assembly.xml file.
         </p>
  -    </s2>
  -    <s2 title="Log messages">
  +    </subsection>
  +    <subsection title="Log messages">
         <p>
         Refactor Log messages so that they are structured in a manner more
         suitable for administrators rather than developers.
  @@ -76,9 +76,9 @@
         <p>
         update 12/05/02: mostly done.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Generated Configurations">
  +    <subsection title="Generated Configurations">
         <p>
         Define and implement a smart way to generate Avalon configurations.
         Define configuration template containing default configuration,
  @@ -86,24 +86,24 @@
         implement code to merge all servers configuration file to a single Avalon
         configuration file.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Time Scheduler changes">
  +    <subsection title="Time Scheduler changes">
         <p>
         Rework the DefaultTimeScheduler so that entrys are removed from heap when
         reset. Otherwise it could lead to excessive buildup of invalidated entries
         if many are reset but remain in heap.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Opening some tightly kernel-coupled services">
  +    <subsection title="Opening some tightly kernel-coupled services">
         <p>
         Rework kernel so that ConfigurationRepository, Logging and Management can
         be routed through ServerApplications.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Virtual File System / Jars within Jars">
  +    <subsection title="Virtual File System / Jars within Jars">
         <p>
         Implement a simple read-only VFS so that .sar files do not need to be
         expanded.
  @@ -111,16 +111,16 @@
         <p>
         update 12/05/02: done.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Thread pooling">
  +    <subsection title="Thread pooling">
         <p>
         Rework kernel so that thread boundaries are respected and secure. This essentially
         involves using ThreadPools to execute phases and for management.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="JNDI service">
  +    <subsection title="JNDI service">
         <p>
         Determine if we need a naming service. If so provide a simple JNDI based naming
         service possibly built on top of cadastre.
  @@ -128,24 +128,24 @@
         <p>
         update 12/05/02: we've decided not to do so at this time.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Block Management remotely">
  +    <subsection title="Block Management remotely">
         <p>
         Separate out and specify the way in which different parts of system are managed.
         ie Compare how remote Management of Blocks could occur vs Deployer/Kernel/Embeddor
         management occurs.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Hot deployment">
  +    <subsection title="Hot deployment">
         <p>
         A standard system for hot deploying and undeploying. This may require the building
         of FileMonitors that will read a file when it is changed.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Reconfiguration">
  +    <subsection title="Reconfiguration">
         <p><strong>This has a few facets:</strong></p>
         <p>
         A standard reconfiguration system.  This may require the building
  @@ -165,59 +165,59 @@
         runtime.
         </p>
   
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Proxy Interfaces">
  +    <subsection title="Proxy Interfaces">
         <p>
         Currently services are provided via a proxy interface. Rework kernel so that
         the proxy interface can be turned off via a command-line switch.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Management Console">
  +    <subsection title="Management Console">
         <p>
         Management console/Client interface. CLI version aswell as a GUI version.
         </p>
         <p>
         update 12/05/02: we have a draft of concept.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Default JNDI Contexts">
  +    <subsection title="Default JNDI Contexts">
         <p>
         Avalon should provide default JNDI contexts
         that Block implementers can extend and use like
         Context, EventContext, and DirectoryContext.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Java Messaging Service">
  +    <subsection title="Java Messaging Service">
         <p>
         JMS (Java Messaging Service) for the Connection Manager. It
         will provide a standard and flexible connection service and
         messaging service. It allows for both point to point messaging
         and multicast messaging (subscriber/provider).
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Server Pools">
  +    <subsection title="Server Pools">
         <p>
         Support for server pools.  Several Phoenix servers should be able
         to pool resources and act as one server regardless of VM, or
         physical machine they are on.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Block loading remotely">
  +    <subsection title="Block loading remotely">
         <p>
         Remote loading of Blocks. Phoenix should be able to pull a block
         at run time from a remote server, check the signature, and run it
         with proper permissions.  This would allow for the possibility of
         automatically upgrading blocks.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Remote Control">
  +    <subsection title="Remote Control">
         <p>
         Write some code to remotely control Phoenix. (This will most likely be
         rolled into JMX support).
  @@ -225,40 +225,40 @@
         <p>
         update 12/05/02: done (through jmx).
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Transactions">
  +    <subsection title="Transactions">
         <p>
         Define and implement some Transaction pattern for the Repository. Maybe JTA?
         </p>
  -    </s2>
  +    </subsection>
   </section>
   
   <section name="Ongoing work">
  -    <s2 title="Help needed!">
  +    <subsection title="Help needed!">
         <p>
         We can really use some help here! This is a top priority and all
         contributions will be welcomed.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="Documentation">
  +    <subsection title="Documentation">
         <p>
         Write all documentation.
         </p>
  -    </s2>
  +    </subsection>
   
  -    <s2 title="JavaDocs">
  +    <subsection title="JavaDocs">
         <p>
         Update JavaDocs for decent developer documentation.
         </p>
  -    </s2>
  +    </subsection>
   
   </section>
   
   <section name="Very Important Work to Complete">
   
  -    <s2 title="Java Management eXtentions">
  +    <subsection title="Java Management eXtentions">
         <p>
         JMX (Java Management eXtentions) for central management of
         Avalon. If JMX cannot be done due to licensing, we should
  @@ -269,7 +269,7 @@
         update 12/05/02: we're at roughly 80% functionality. We're
         using MX4J as our default MBeanServer.
         </p>
  -    </s2>
  +    </subsection>
   
   </section>
   
  
  
  
  1.1.2.2   +4 -4      jakarta-avalon-phoenix/src/xdocs/guide-administrator.xml
  
  Index: guide-administrator.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-administrator.xml,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- guide-administrator.xml	21 May 2002 11:58:19 -0000	1.1.2.1
  +++ guide-administrator.xml	21 May 2002 12:17:28 -0000	1.1.2.2
  @@ -15,20 +15,20 @@
           The framework defines a standard method of piecing together server
           components and creating a server.
         </p>
  -      <s2 title="Target Audience">
  +      <subsection title="Target Audience">
           <p>
             This documentation will describe the care and feeding of the Avalon
             Phoenix kernel from the point of view of the administrator.
           </p>
  -      </s2>
  -      <s2 title="Guide non-existent, but features are there">
  +      </subsection>
  +      <subsection title="Guide non-existent, but features are there">
   	<p>
             We currently have no info on this whatsoever. However, this doesn't
   	  mean that Phoenix is not easy to administrate - the contrary is true,
   	  since our tight integration with JMX exposes the entire kernel at
   	  runtime.
           </p>
  -      </s2>
  +      </subsection>
       </section>
     </body>
   </document>
  
  
  
  1.1.2.2   +6 -6      jakarta-avalon-phoenix/src/xdocs/guide-architecture.xml
  
  Index: guide-architecture.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-architecture.xml,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- guide-architecture.xml	21 May 2002 11:58:19 -0000	1.1.2.1
  +++ guide-architecture.xml	21 May 2002 12:17:28 -0000	1.1.2.2
  @@ -36,7 +36,7 @@
         <p>
           Phoenix application are distriuted in a single archive.
         </p>
  -      <s2 title="Packaging in terms of blocks">
  +      <subsection title="Packaging in terms of blocks">
           <p>
             Phoenix hosts server applications made up of blocks.  The blocks may depend on
libraries
             to function correctly.  The blocks are tied together with Assembly instructions
and Configured
  @@ -46,8 +46,8 @@
             <title>Phoenix application in block view</title>
             <graphic srccredit="Paul Hammant, 2001" fileref="images/phoenix-app-block.jpg"
format="JPEG"/>
           </figure>
  -      </s2>
  -      <s2 title="Packaging in terms of block jar files">
  +      </subsection>
  +      <subsection title="Packaging in terms of block jar files">
           <p>
             The server application is entirely contained withing one "sar" file.  Sar is
"Server ARchive".
             Each block is a jar file.  The dependant libraries are regular jars (placed
  @@ -58,8 +58,8 @@
             <title>Phoenix application in block jar view</title>
             <graphic srccredit="Paul Hammant, 2001" fileref="images/phoenix-app-blockjars.jpg"
format="JPEG"/>
           </figure>
  -      </s2>
  -      <s2 title="FtpServer as a Phoenix application">
  +      </subsection>
  +      <subsection title="FtpServer as a Phoenix application">
         <p>
           FtpServer (part of the Avalon/Cornerstone project) is distributed in sar form.
 Here is a
           view of it's blocks.  It has no third party jars that it depends on.
  @@ -68,7 +68,7 @@
             <title>FtpServer, a real Phoenix application</title>
             <graphic srccredit="Paul Hammant, 2001" fileref="images/phoenix-app-ftpserver.jpg"
format="JPEG"/>
           </figure>
  -      </s2>
  +      </subsection>
         <p>
           Notes - Phoenix does not limit the number of blocks that it allows in a sar file.
 We have taksdefs for Apache's Ant
           tool for making sar files.  See the "Block Developers Guide" (left
  
  
  
  1.1.2.2   +8 -8      jakarta-avalon-phoenix/src/xdocs/guide-block-developers-making-phoenix-compatible-comps.xml
  
  Index: guide-block-developers-making-phoenix-compatible-comps.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-block-developers-making-phoenix-compatible-comps.xml,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- guide-block-developers-making-phoenix-compatible-comps.xml	21 May 2002 11:58:19 -0000
1.1.2.1
  +++ guide-block-developers-making-phoenix-compatible-comps.xml	21 May 2002 12:17:28 -0000
1.1.2.2
  @@ -20,7 +20,7 @@
           There are a number of common sense things to remember when making or
           adapting a Java component to be reusable in Phoenix as block.
         </p>
  -      <s2 title="Beanification">
  +      <subsection title="Beanification">
           <p>
             <ul>
               <li>Have a public empty constructor for your main class</li>
  @@ -33,12 +33,12 @@
               <li>Try to avoid Singleton concepts.  There could be multiple blocks
in one sar using differnt (by design) instances of your bean</li>
             </ul>
           </p>
  -      </s2>
  -      <s2 title="Inversion of Control Pattern">
  +      </subsection>
  +      <subsection title="Inversion of Control Pattern">
            The IoC pattern is described <a href="http://jakarta.apache.org/avalon/framework/inversion-of-control.html">
            here</a>.  This means for Phoenix avoiding static concepts including loggers.
  -      </s2>
  -      <s2 title="Sepearation of interface and implementation">
  +      </subsection>
  +      <subsection title="Sepearation of interface and implementation">
           <p>
            The separation of interface/impl pattern is described <a href="http://jakarta.apache.org/avalon/framework/separation-of-interface-and-implementation.html">here</a>.
            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
  @@ -46,8 +46,8 @@
            journal some methods, but still delegate to the real impl.  Which pluggable impl
is used by Phoenix when it
            boots is determined in assembly.xml of course.
           </p>
  -      </s2>
  -      <s2 title="Opening up the API">
  +      </subsection>
  +      <subsection title="Opening up the API">
           <p>
            Given that you have divided into interface and impl, 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
  @@ -61,7 +61,7 @@
           </ol>
           .. might be useful.  Just because you can only see a ServerSocket interface does
not mean that others do.
           </p>
  -      </s2>
  +      </subsection>
       </section>
       <section name="Example compatible comp">
       <p>
  
  
  
  1.1.2.2   +2 -2      jakarta-avalon-phoenix/src/xdocs/guide-deployers.xml
  
  Index: guide-deployers.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-deployers.xml,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- guide-deployers.xml	21 May 2002 11:58:19 -0000	1.1.2.1
  +++ guide-deployers.xml	21 May 2002 12:17:28 -0000	1.1.2.2
  @@ -15,13 +15,13 @@
           and restarting Phoenix. In the future there will be more advanced methods
           of deploying and undeploying Server Applications without restarting Phoenix.
         </p>
  -      <s2 title="Target Audience">
  +      <subsection title="Target Audience">
           <p>
             This documentation describes the methods through which you can deploy
             Server Applications under the Phoenix kernel. It will be expanded as
             the system becomes more complete.
           </p>
  -      </s2>
  +      </subsection>
       </section>
     </body>
   </document>
  
  
  
  1.7.2.2   +4 -4      jakarta-avalon-phoenix/src/xdocs/index.xml
  
  Index: index.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/index.xml,v
  retrieving revision 1.7.2.1
  retrieving revision 1.7.2.2
  diff -u -r1.7.2.1 -r1.7.2.2
  --- index.xml	21 May 2002 11:58:19 -0000	1.7.2.1
  +++ index.xml	21 May 2002 12:17:28 -0000	1.7.2.2
  @@ -33,7 +33,7 @@
   	the different roles that typically exist in daily use of phoenix. For each of
   	these, we provide a basic guide. We finish with a complete example.
         </p>
  -        <s2 title="Target Audience">
  +        <subsection title="Target Audience">
             <p>
               This documentation is aimed towards people who:
               <ul>
  @@ -45,8 +45,8 @@
                 <li>wish to reuse Avalon Phoenix concepts in their own application</li>
               </ul>
             </p>
  -        </s2>
  -        <s2 title="Contents">
  +        </subsection>
  +        <subsection title="Contents">
             <ol>
               <li><a href="guide-architecture.html">Architectural overview</a></li>
               <li><a href="guide-roles.html">Development roles</a></li>
  @@ -56,7 +56,7 @@
               <li><a href="guide-block-developers.html">Block Developer Guide</a></li>
               <li><a href="guide-example-configuration.html">Example Configuration.</a></li>
             </ol>
  -        </s2>
  +        </subsection>
       </section>
       <section name="Avalon Phoenix Reference Documentation">
         <p>
  
  
  
  1.1.2.2   +6 -6      jakarta-avalon-phoenix/src/xdocs/reference-blockinfo-specification.xml
  
  Index: reference-blockinfo-specification.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/reference-blockinfo-specification.xml,v
  retrieving revision 1.1.2.1
  retrieving revision 1.1.2.2
  diff -u -r1.1.2.1 -r1.1.2.2
  --- reference-blockinfo-specification.xml	21 May 2002 11:58:19 -0000	1.1.2.1
  +++ reference-blockinfo-specification.xml	21 May 2002 12:17:28 -0000	1.1.2.2
  @@ -68,18 +68,18 @@
           three main sections; <code>block</code>, <code>services</code>
and
           <code>dependencies</code>.
         </p>
  -      <s2 title="BlockInfo 'block' Section">
  +      <subsection title="BlockInfo 'block' Section">
           <p>The block section specifies the version of class. In the future this
           section will also specify the configuration schema if the block is
           <code>Configurable</code>.</p>
  -      </s2>
  -      <s2 title="BlockInfo 'services' Section">
  +      </subsection>
  +      <subsection title="BlockInfo 'services' Section">
           <p>The services section documents the services that this block can offer
other
           Blocks. The service instances indicate an interface and a version. The interface
           MUST extend <code>org.apache.phoenix.Service</code>. This section is
optional
           and a Block can choose to not offer any services.</p>
  -      </s2>
  -      <s2 title="BlockInfo 'dependencies' Section">
  +      </subsection>
  +      <subsection title="BlockInfo 'dependencies' Section">
           <p>The services section documents the services that this block requires to
operate.
           Required services are placed in the Blocks ComponentManager under the name
           specified by the <code>role</code> element of dependency. As is documented
in the
  @@ -89,7 +89,7 @@
           cases however the role element and the name attribute of the service will be
           identical. In these cases it is sufficient to just specify service element and
role
           will default to name of service.</p>
  -      </s2>
  +      </subsection>
       </section>
     </body>
   </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