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:18:32 GMT
donaldp     02/05/21 05:18:32

  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:
  title->name
  
  Revision  Changes    Path
  No                   revision
  
  
  No                   revision
  
  
  1.1.2.3   +23 -23    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.2
  retrieving revision 1.1.2.3
  diff -u -r1.1.2.2 -r1.1.2.3
  --- for-developers-todo.xml	21 May 2002 12:17:28 -0000	1.1.2.2
  +++ for-developers-todo.xml	21 May 2002 12:18:32 -0000	1.1.2.3
  @@ -61,14 +61,14 @@
   
   <section name="Wish List">
   
  -    <subsection title="Separate and Antify Validation code">
  +    <subsection name="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>
       </subsection>
  -    <subsection title="Log messages">
  +    <subsection name="Log messages">
         <p>
         Refactor Log messages so that they are structured in a manner more
         suitable for administrators rather than developers.
  @@ -78,7 +78,7 @@
         </p>
       </subsection>
   
  -    <subsection title="Generated Configurations">
  +    <subsection name="Generated Configurations">
         <p>
         Define and implement a smart way to generate Avalon configurations.
         Define configuration template containing default configuration,
  @@ -88,7 +88,7 @@
         </p>
       </subsection>
   
  -    <subsection title="Time Scheduler changes">
  +    <subsection name="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
  @@ -96,14 +96,14 @@
         </p>
       </subsection>
   
  -    <subsection title="Opening some tightly kernel-coupled services">
  +    <subsection name="Opening some tightly kernel-coupled services">
         <p>
         Rework kernel so that ConfigurationRepository, Logging and Management can
         be routed through ServerApplications.
         </p>
       </subsection>
   
  -    <subsection title="Virtual File System / Jars within Jars">
  +    <subsection name="Virtual File System / Jars within Jars">
         <p>
         Implement a simple read-only VFS so that .sar files do not need to be
         expanded.
  @@ -113,14 +113,14 @@
         </p>
       </subsection>
   
  -    <subsection title="Thread pooling">
  +    <subsection name="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>
       </subsection>
   
  -    <subsection title="JNDI service">
  +    <subsection name="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.
  @@ -130,7 +130,7 @@
         </p>
       </subsection>
   
  -    <subsection title="Block Management remotely">
  +    <subsection name="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
  @@ -138,14 +138,14 @@
         </p>
       </subsection>
   
  -    <subsection title="Hot deployment">
  +    <subsection name="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>
       </subsection>
   
  -    <subsection title="Reconfiguration">
  +    <subsection name="Reconfiguration">
         <p><strong>This has a few facets:</strong></p>
         <p>
         A standard reconfiguration system.  This may require the building
  @@ -167,14 +167,14 @@
   
       </subsection>
   
  -    <subsection title="Proxy Interfaces">
  +    <subsection name="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>
       </subsection>
   
  -    <subsection title="Management Console">
  +    <subsection name="Management Console">
         <p>
         Management console/Client interface. CLI version aswell as a GUI version.
         </p>
  @@ -183,7 +183,7 @@
         </p>
       </subsection>
   
  -    <subsection title="Default JNDI Contexts">
  +    <subsection name="Default JNDI Contexts">
         <p>
         Avalon should provide default JNDI contexts
         that Block implementers can extend and use like
  @@ -191,7 +191,7 @@
         </p>
       </subsection>
   
  -    <subsection title="Java Messaging Service">
  +    <subsection name="Java Messaging Service">
         <p>
         JMS (Java Messaging Service) for the Connection Manager. It
         will provide a standard and flexible connection service and
  @@ -200,7 +200,7 @@
         </p>
       </subsection>
   
  -    <subsection title="Server Pools">
  +    <subsection name="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
  @@ -208,7 +208,7 @@
         </p>
       </subsection>
   
  -    <subsection title="Block loading remotely">
  +    <subsection name="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
  @@ -217,7 +217,7 @@
         </p>
       </subsection>
   
  -    <subsection title="Remote Control">
  +    <subsection name="Remote Control">
         <p>
         Write some code to remotely control Phoenix. (This will most likely be
         rolled into JMX support).
  @@ -227,7 +227,7 @@
         </p>
       </subsection>
   
  -    <subsection title="Transactions">
  +    <subsection name="Transactions">
         <p>
         Define and implement some Transaction pattern for the Repository. Maybe JTA?
         </p>
  @@ -235,20 +235,20 @@
   </section>
   
   <section name="Ongoing work">
  -    <subsection title="Help needed!">
  +    <subsection name="Help needed!">
         <p>
         We can really use some help here! This is a top priority and all
         contributions will be welcomed.
         </p>
       </subsection>
   
  -    <subsection title="Documentation">
  +    <subsection name="Documentation">
         <p>
         Write all documentation.
         </p>
       </subsection>
   
  -    <subsection title="JavaDocs">
  +    <subsection name="JavaDocs">
         <p>
         Update JavaDocs for decent developer documentation.
         </p>
  @@ -258,7 +258,7 @@
   
   <section name="Very Important Work to Complete">
   
  -    <subsection title="Java Management eXtentions">
  +    <subsection name="Java Management eXtentions">
         <p>
         JMX (Java Management eXtentions) for central management of
         Avalon. If JMX cannot be done due to licensing, we should
  
  
  
  1.1.2.3   +2 -2      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.2
  retrieving revision 1.1.2.3
  diff -u -r1.1.2.2 -r1.1.2.3
  --- guide-administrator.xml	21 May 2002 12:17:28 -0000	1.1.2.2
  +++ guide-administrator.xml	21 May 2002 12:18:32 -0000	1.1.2.3
  @@ -15,13 +15,13 @@
           The framework defines a standard method of piecing together server
           components and creating a server.
         </p>
  -      <subsection title="Target Audience">
  +      <subsection name="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>
         </subsection>
  -      <subsection title="Guide non-existent, but features are there">
  +      <subsection name="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,
  
  
  
  1.1.2.3   +3 -3      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.2
  retrieving revision 1.1.2.3
  diff -u -r1.1.2.2 -r1.1.2.3
  --- guide-architecture.xml	21 May 2002 12:17:28 -0000	1.1.2.2
  +++ guide-architecture.xml	21 May 2002 12:18:32 -0000	1.1.2.3
  @@ -36,7 +36,7 @@
         <p>
           Phoenix application are distriuted in a single archive.
         </p>
  -      <subsection title="Packaging in terms of blocks">
  +      <subsection name="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
  @@ -47,7 +47,7 @@
             <graphic srccredit="Paul Hammant, 2001" fileref="images/phoenix-app-block.jpg"
format="JPEG"/>
           </figure>
         </subsection>
  -      <subsection title="Packaging in terms of block jar files">
  +      <subsection name="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
  @@ -59,7 +59,7 @@
             <graphic srccredit="Paul Hammant, 2001" fileref="images/phoenix-app-blockjars.jpg"
format="JPEG"/>
           </figure>
         </subsection>
  -      <subsection title="FtpServer as a Phoenix application">
  +      <subsection name="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.
  
  
  
  1.1.2.3   +4 -4      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.2
  retrieving revision 1.1.2.3
  diff -u -r1.1.2.2 -r1.1.2.3
  --- guide-block-developers-making-phoenix-compatible-comps.xml	21 May 2002 12:17:28 -0000
1.1.2.2
  +++ guide-block-developers-making-phoenix-compatible-comps.xml	21 May 2002 12:18:32 -0000
1.1.2.3
  @@ -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>
  -      <subsection title="Beanification">
  +      <subsection name="Beanification">
           <p>
             <ul>
               <li>Have a public empty constructor for your main class</li>
  @@ -34,11 +34,11 @@
             </ul>
           </p>
         </subsection>
  -      <subsection title="Inversion of Control Pattern">
  +      <subsection name="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.
         </subsection>
  -      <subsection title="Sepearation of interface and implementation">
  +      <subsection name="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
  @@ -47,7 +47,7 @@
            boots is determined in assembly.xml of course.
           </p>
         </subsection>
  -      <subsection title="Opening up the API">
  +      <subsection name="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
  
  
  
  1.1.2.3   +1 -1      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.2
  retrieving revision 1.1.2.3
  diff -u -r1.1.2.2 -r1.1.2.3
  --- guide-deployers.xml	21 May 2002 12:17:28 -0000	1.1.2.2
  +++ guide-deployers.xml	21 May 2002 12:18:32 -0000	1.1.2.3
  @@ -15,7 +15,7 @@
           and restarting Phoenix. In the future there will be more advanced methods
           of deploying and undeploying Server Applications without restarting Phoenix.
         </p>
  -      <subsection title="Target Audience">
  +      <subsection name="Target Audience">
           <p>
             This documentation describes the methods through which you can deploy
             Server Applications under the Phoenix kernel. It will be expanded as
  
  
  
  1.7.2.3   +2 -2      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.2
  retrieving revision 1.7.2.3
  diff -u -r1.7.2.2 -r1.7.2.3
  --- index.xml	21 May 2002 12:17:28 -0000	1.7.2.2
  +++ index.xml	21 May 2002 12:18:32 -0000	1.7.2.3
  @@ -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>
  -        <subsection title="Target Audience">
  +        <subsection name="Target Audience">
             <p>
               This documentation is aimed towards people who:
               <ul>
  @@ -46,7 +46,7 @@
               </ul>
             </p>
           </subsection>
  -        <subsection title="Contents">
  +        <subsection name="Contents">
             <ol>
               <li><a href="guide-architecture.html">Architectural overview</a></li>
               <li><a href="guide-roles.html">Development roles</a></li>
  
  
  
  1.1.2.3   +3 -3      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.2
  retrieving revision 1.1.2.3
  diff -u -r1.1.2.2 -r1.1.2.3
  --- reference-blockinfo-specification.xml	21 May 2002 12:17:28 -0000	1.1.2.2
  +++ reference-blockinfo-specification.xml	21 May 2002 12:18:32 -0000	1.1.2.3
  @@ -68,18 +68,18 @@
           three main sections; <code>block</code>, <code>services</code>
and
           <code>dependencies</code>.
         </p>
  -      <subsection title="BlockInfo 'block' Section">
  +      <subsection name="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>
         </subsection>
  -      <subsection title="BlockInfo 'services' Section">
  +      <subsection name="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>
         </subsection>
  -      <subsection title="BlockInfo 'dependencies' Section">
  +      <subsection name="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
  
  
  

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