You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by do...@apache.org on 2002/05/21 14:17:28 UTC
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
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>