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 13:58:20 UTC
cvs commit: jakarta-avalon-phoenix/src/xdocs/stylesheets docs.vsl project.xml templates.vm velocity.properties
donaldp 02/05/21 04:58:20
Modified: src/xdocs Tag: ANAKIA_DOCS features.xml
for-developers-a-future.xml
for-developers-changes.xml
for-developers-project-structure.xml
for-developers-todo.xml getting-started.xml
guide-administrator.xml guide-architecture.xml
guide-assemblers-creating-a-server-application.xml
guide-assemblers-what-is-a-server-application.xml
guide-assemblers.xml
guide-block-developers-creating-a-block.xml
guide-block-developers-making-phoenix-compatible-comps.xml
guide-block-developers-what-is-a-block-listener.xml
guide-block-developers-what-is-a-block.xml
guide-block-developers-what-is-an-application-listener.xml
guide-block-developers.xml guide-deployers.xml
guide-example-configuration.xml guide-roles.xml
index.xml install.xml
reference-assembly-xml-specification.xml
reference-blockinfo-specification.xml
reference-config-xml-specification.xml
reference-environment-xml-specification.xml
Added: src/xdocs/images Tag: ANAKIA_DOCS header.gif
src/xdocs/stylesheets Tag: ANAKIA_DOCS docs.vsl project.xml
templates.vm velocity.properties
Removed: src/xdocs Tag: ANAKIA_DOCS book.xml
src/xdocs/dtd Tag: ANAKIA_DOCS document-v10.dtd
Log:
Start to refactor docs so that we can use Anakia to generate documentation.
Revision Changes Path
No revision
No revision
1.5.2.1 +14 -16 jakarta-avalon-phoenix/src/xdocs/features.xml
Index: features.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/features.xml,v
retrieving revision 1.5
retrieving revision 1.5.2.1
diff -u -r1.5 -r1.5.2.1
--- features.xml 12 May 2002 20:57:14 -0000 1.5
+++ features.xml 21 May 2002 11:58:19 -0000 1.5.2.1
@@ -1,43 +1,41 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Features</title>
- <authors>
- <person name="Leo Simons" email="leosimons@apache.org"/>
- </authors>
+ <title>Features</title>
+
+ <author name="Leo Simons" email="leosimons@apache.org"/>
+
</header>
<body>
-<s1 title="Introduction">
+<section name="Introduction">
<p>This document is not complete yet...</p>
-</s1>
+</section>
-<s1 title="Extensible architecture">
+<section name="Extensible architecture">
<p>Phoenix is written as an extensible micro-kernel. This allows you to:</p>
<ul>
<li>Customise behaviour quickly</li>
<li>Plug in extra functionality effortlessly</li>
<li>remove unneeded functionality for a small footprint</li>
</ul>
-</s1>
+</section>
-<s1 title="Flexible environment">
+<section name="Flexible environment">
<p>Phoenix has native support for use in the following environments:</p>
<ul>
<li>command-line stand-alone program</li>
<li>Unix daemon</li>
<li>Embedded in other programs (including servlet engines)</li>
</ul>
-</s1>
+</section>
-<s1 title="Integrated management">
+<section name="Integrated management">
<p>Phoenix enables JMX management of your software:</p>
<ul>
<li>All aspects of phoenix itself are manageable, including
@@ -46,9 +44,9 @@
their lifecycle (configuration, startup/shutdown, etc) and
everything else you mark as manageable.</li>
</ul>
-</s1>
+</section>
-<s1 title="Ease and speed up application development">
+<section name="Ease and speed up application development">
<p>Phoenix is a container for (server) applications. It can host
multiple applications within the same JVM, while keeping them securely
isolated from each other.</p>
@@ -70,7 +68,7 @@
<p>Phoenix leverages the Avalon Framework, making it compatible with other
Avalon-based projects like Excalibur and Cornerstone, enabling you to
easily reuse their functionality.</p>
-</s1>
+</section>
</body>
</document>
1.1.2.1 +14 -16 jakarta-avalon-phoenix/src/xdocs/for-developers-a-future.xml
Index: for-developers-a-future.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/for-developers-a-future.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- for-developers-a-future.xml 12 May 2002 19:52:49 -0000 1.1
+++ for-developers-a-future.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,36 +1,34 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - A future</title>
- <authors>
- <person name="Paul Hammant" email="Paul_Hammant@yahoo.com"/>
- </authors>
+ <title>A future</title>
+
+ <author name="Paul Hammant" email="Paul_Hammant@yahoo.com"/>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
A long term aim of Phoenix is to provide a platform that hosts multiple third party applications written only in Java within a single virtual machine. The Phoenix platform is currently hosted on an Operating System such as Unix, Windows or Mac. It could function directly on top of a Java Operating System. A CPU combined with a suitable amount of memory, a basic BIOS, a Kernal, a suitable JVM and runtime library, could mount Phoenix and hosted server applications.
- </p>
- </s1>
- <s1 title="One step further">
+ </p>
+ </section>
+ <section name="One step further">
<p>
Imagine Sun making such a box under their own name or as Cobalt, using low power chips from their own stable or perhaps a StrongARM. That machine could be rack mounted like their current X1:
- </p>
+ </p>
<figure>
<title>Sun X1</title>
- <graphic srccredit="© Sun Microsystems" fileref="http://www.sun.com/products-n-solutions/hw/networking/images/prodsplash/x1.jpg" format="JPEG"/>
- </figure>
+ <graphic srccredit="© Sun Microsystems" fileref="http://www.sun.com/products-n-solutions/hw/networking/images/prodsplash/x1.jpg" format="JPEG"/>
+ </figure>
<p>
If that rackable server had 32 such CPUs, each with 128Mb of memory all booting Phoenix. And if the CPUs shared a single hard drive, we might have a machine that was tuned to CPU intensive activities. Cocoon/Tomcat, EJB clusters, might be load balanced by one of the CPUs running a Phoenix load balancer. Alternate scenarios are for virtual site hosting. It could be a "1U" render or bean farm with each internal CPU having its own TCP/IP address.
</p>
- </s1>
- <s1 title="Is all this possible?">
+ </section>
+ <section name="Is all this possible?">
<p>
Well there are already romable J2SE implementations that are available for StrongARM chips on Compaq's handheld iPAQ. We are there already, but for the client side rather than the server side.
</p>
- </s1>
+ </section>
</body>
</document>
1.1.2.1 +24 -26 jakarta-avalon-phoenix/src/xdocs/for-developers-changes.xml
Index: for-developers-changes.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/for-developers-changes.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- for-developers-changes.xml 12 May 2002 19:52:49 -0000 1.1
+++ for-developers-changes.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,14 +1,12 @@
<?xml version="1.0"?>
-<!DOCTYPE changes SYSTEM "dtd/changes-v10.dtd">
-
<changes title="Avalon Phoenix - History of Changes">
<devs>
- <person name="Federico Barbieri" email="fede@apache.org" id="FB"/>
- <person name="Berin Loritsch" email="bloritsch@apache.org" id="BL"/>
- <person name="Peter Donald" email="peter@apache.org" id="PD"/>
- <person name="Paul Hammant" email="Paul_Hammant@yahoo.com" id="PH"/>
- <person name="Mircea Toma" email="mirceatoma@home.com" id="MT"/>
+ <author name="Federico Barbieri" email="fede@apache.org" id="FB"/>
+ <author name="Berin Loritsch" email="bloritsch@apache.org" id="BL"/>
+ <author name="Peter Donald" email="peter@apache.org" id="PD"/>
+ <author name="Paul Hammant" email="Paul_Hammant@yahoo.com" id="PH"/>
+ <author name="Mircea Toma" email="mirceatoma@home.com" id="MT"/>
</devs>
<release version="4.0a3" date="November 13, 2001">
<action dev="PD" type="change">
@@ -22,24 +20,24 @@
<release version="4.0a2" date="November 12, 2001">
<action dev="PD" type="change">
Update Phoenix to use the new Avalon Framework Logger interface rather than
- directly using LogKits Logger class. This required a backwards incompatible
+ directly using LogKits Logger class. This required a backwards incompatible
change in BlockContext. The getLogger() methods now return the Logger interface
rather than LogKits Logger class. If a Block implements Loggable then it will
- be passed LogKits Logger, this is required for backwards compatability. If the
+ be passed LogKits Logger, this is required for backwards compatability. If the
Block implements LogEnabled it will receive the new style Logger.
</action>
<action dev="MT" type="add">
Add support for undeploying and unistalling applications. Add support for separating
- out install phase from deployment phase and persisting information about
+ out install phase from deployment phase and persisting information about
application installations.
</action>
<action dev="PD" type="change">
Rework the application deployment format (ie .sar format) to be more in line
- with other specifications. See docs/creating-a-server-application.html in distribution
+ with other specifications. See docs/creating-a-server-application.html in distribution
for current format description. The old format is deprecated but will still work.
</action>
<action dev="PH" type="add">
- Created the start of a Phoenix Developers Kit (PDK) that will enable
+ Created the start of a Phoenix Developers Kit (PDK) that will enable
developers to rapidly become accustom to developing Phoenix applications.
</action>
<action dev="PD" type="add">
@@ -47,10 +45,10 @@
doing this by refactoring the base MBeans and testing using the RIs agent.
</action>
<action dev="PD" type="change">
- Separated code that validated assembly of application into separate
- classes. The validation is now much stricter and requires that
+ Separated code that validated assembly of application into separate
+ classes. The validation is now much stricter and requires that
Blocks conform to established patterns. The validation phase should give
- more reasonable explanations for violations. Extra validation checks
+ more reasonable explanations for violations. Extra validation checks
include verifying that services offered by a Block are actually interfaces,
that there is no circular dependencies, that declared Blocks and BlockListeners
actually implement Block or BlockListener interface, that the names of Blocks
@@ -77,30 +75,30 @@
removed.
</action>
<action dev="PD" type="update">
- Simplified Loader and made it set ContextClassLoader before executing
+ Simplified Loader and made it set ContextClassLoader before executing
Main method. It will also use the System property phoenix.home if set
rather than always trying to dynamically determine home directory.
</action>
<action dev="PD" type="add">
- Added SingleAppEmbeddor to launch a kernel to load a single Application.
- Patch supplied by "Eung-ju Park" (colus@isoft.co.kr). This is useful if
+ Added SingleAppEmbeddor to launch a kernel to load a single Application.
+ Patch supplied by "Eung-ju Park" (colus@isoft.co.kr). This is useful if
you need to reuse the blocks in other contexts (such as in a Servlet).
</action>
<action dev="PD" type="add">
- Made default SystemManager a NoopSystemManager. Patch supplied
+ Made default SystemManager a NoopSystemManager. Patch supplied
by "Eung-ju Park" (colus@isoft.co.kr). To re-enable RMI manager a new
command line switch "--remote-manager" was added.
</action>
<action dev="PD" type="update">
- Reworked SecurityManager setup. Instead of starting a security
+ Reworked SecurityManager setup. Instead of starting a security
Manager inside the code it has been re-architectured so that the
SecurityManager is set on the command line. This was to avoid a number
of issues related to creating a URLClassLoader in an unprotected context
- before setting SecurityManager. ie As AccessControllerContext was null it
- is impossible to use ClassLoader.getResource(AsStream)(). This means that
- defining phoenix.insecure will no longer disable the SecurityManager. The
- replacement method is to set the native OS environment variable
- 'PHOENIX_SECURE=false'.
+ before setting SecurityManager. ie As AccessControllerContext was null it
+ is impossible to use ClassLoader.getResource(AsStream)(). This means that
+ defining phoenix.insecure will no longer disable the SecurityManager. The
+ replacement method is to set the native OS environment variable
+ 'PHOENIX_SECURE=false'.
</action>
<action dev="PD" type="update">
Separate Parsing of CLI arguements into separate class (CLISetup).
@@ -108,7 +106,7 @@
Tomcats Services API.
</action>
<action dev="PD" type="add">
- Started Localizing text strings throughout Phoenix. This is done using
+ Started Localizing text strings throughout Phoenix. This is done using
ResourceManager and Resources from Avalon/Excalibur project.
</action>
</release>
1.1.2.1 +10 -18 jakarta-avalon-phoenix/src/xdocs/for-developers-project-structure.xml
Index: for-developers-project-structure.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/for-developers-project-structure.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- for-developers-project-structure.xml 12 May 2002 19:52:49 -0000 1.1
+++ for-developers-project-structure.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,22 +1,20 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Project Structure</title>
- <authors>
- <person name="Leo Simons" email="leosimons@apache.org"/>
- </authors>
+ <title>Project Structure</title>
+
+ <author name="Leo Simons" email="leosimons@apache.org"/>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>Avalon Phoenix has seen lots of refactoring to create an intuitive
code layout. It is usually quite easy to find what you need. This document
provides an overview of the project structure. It is still under
construction.</p>
- </s1>
- <s1 title="Package structure">
+ </section>
+ <section name="Package structure">
<source>
org.apache.avalon.phoenix
|
@@ -45,8 +43,8 @@
|- verifier
|- xdoclet
</source>
- </s1>
- <s1 title="CVS Directory structure">
+ </section>
+ <section name="CVS Directory structure">
<source>
jakarta-avalon
|
@@ -77,13 +75,7 @@
|- README.txt
|- WARNING.txt
</source>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:49 $
- </legal>
- </footer>
</document>
1.1.2.1 +13 -15 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
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- for-developers-todo.xml 12 May 2002 19:52:49 -0000 1.1
+++ for-developers-todo.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,22 +1,20 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Todo</title>
- <authors>
- <person name="Avalon Documentation Team" email="avalon-dev@jakarta.apache.org"/>
- </authors>
+ <title>Todo</title>
+
+ <author name="Avalon Documentation Team" email="avalon-dev@jakarta.apache.org"/>
+
</header>
<body>
-<s1 title="Todo">
+<section name="Todo">
<p>
-This document describes functionality that is either missing or not finished
+This document describes functionality that is either missing or not finished
within Phoenix.
</p>
@@ -59,9 +57,9 @@
list (avalon-dev@jakarta.apache.org) and ask your specific questions there.
</p>
-</s1>
+</section>
-<s1 title="Wish List">
+<section name="Wish List">
<s2 title="Separate and Antify Validation code">
<p>
@@ -234,9 +232,9 @@
Define and implement some Transaction pattern for the Repository. Maybe JTA?
</p>
</s2>
-</s1>
+</section>
-<s1 title="Ongoing work">
+<section name="Ongoing work">
<s2 title="Help needed!">
<p>
We can really use some help here! This is a top priority and all
@@ -256,9 +254,9 @@
</p>
</s2>
-</s1>
+</section>
-<s1 title="Very Important Work to Complete">
+<section name="Very Important Work to Complete">
<s2 title="Java Management eXtentions">
<p>
@@ -273,7 +271,7 @@
</p>
</s2>
-</s1>
+</section>
</body>
</document>
1.4.2.1 +20 -20 jakarta-avalon-phoenix/src/xdocs/getting-started.xml
Index: getting-started.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/getting-started.xml,v
retrieving revision 1.4
retrieving revision 1.4.2.1
diff -u -r1.4 -r1.4.2.1
--- getting-started.xml 12 May 2002 19:52:49 -0000 1.4
+++ getting-started.xml 21 May 2002 11:58:19 -0000 1.4.2.1
@@ -3,28 +3,28 @@
<document>
<header>
- <title>Avalon Phoenix - Getting Started</title>
- <authors>
- <person name="Avalon Documentation Team" email="avalon-dev@jakarta.apache.org"/>
- <person name="Leo Simons" email="email@leosimons.com"/>
- <person name="Paul Hammant" email="Paul_Hammant@yahoo.com"/>
- </authors>
+ <title>Getting Started</title>
+
+ <author name="Avalon Documentation Team" email="avalon-dev@jakarta.apache.org"/>
+ <author name="Leo Simons" email="email@leosimons.com"/>
+ <author name="Paul Hammant" email="Paul_Hammant@yahoo.com"/>
+
</header>
<body>
-<s1 title="Introduction">
+<section name="Introduction">
<p>
This document provides developers with simple documentation for getting
started with Phoenix. For information about the overall structure of
Avalon Framework (on which Phoenix is based), please refer to the
- <link href="@AVALON_BASE@/framework/index.html">Framework documentation</link>.
+ <a href="@AVALON_BASE@/framework/index.html">Framework documentation</a>.
</p>
<p>
Instructions for downloading and installing Phoenix can be found on the
- <link href="install.html">Install</link> document.
+ <a href="install.html">Install</a> document.
</p>
<p>
@@ -32,9 +32,9 @@
to send in patches ;)
</p>
-</s1>
+</section>
-<s1 title="View Detailed API Documentation">
+<section name="View Detailed API Documentation">
<p>
To generate a full set of detailed API documentation for Avalon, go to the base
@@ -49,8 +49,8 @@
</p>
-</s1>
-<s1 title="Run the HelloWorld example">
+</section>
+<section name="Run the HelloWorld example">
<p>
After you have successfully built Phoenix, you can verify that it
@@ -58,9 +58,9 @@
</p>
<p>
Firstly you will need to get the demo-helloword.sar file and drop it into
- the apps directory of Phoenix. Get it from <link href="TODO">TODO</link> or build
- it from its CVS - <link href="http://cvs.apache.org/viewcvs/jakarta-avalon-apps/demo/">
- http://cvs.apache.org/viewcvs/jakarta-avalon-apps/demo/</link>.
+ the apps directory of Phoenix. Get it from <a href="TODO">TODO</a> or build
+ it from its CVS - <a href="http://cvs.apache.org/viewcvs/jakarta-avalon-apps/demo/">
+ http://cvs.apache.org/viewcvs/jakarta-avalon-apps/demo/</a>.
</p>
<p>
Then fire up phoenix with the following command:
@@ -98,8 +98,8 @@
connection management from the Avalon-Cornerstone project, which is good as it allows us to
share connection pooling across multiple servers.
</p>
-</s1>
-<s1 title="The Phoenix Developer Kit - A different example">
+</section>
+<section name="The Phoenix Developer Kit - A different example">
<p>
This self contained kit could be considered a starter project for someone wanting to make a
Phoenix compatible application. The idea is that you start with this skeleton including
@@ -113,7 +113,7 @@
</p>
<p>
The Phoenix development kit originates in Phoenix's CVS, but for convenience is downloadable
- from <link href="TODO">TODO</link>. When you have that file, unzip it and immediately launch
+ from <a href="TODO">TODO</a>. When you have that file, unzip it and immediately launch
ant to make the jars and sars. There are four:
<ol>
<li>phoenix-demo.sar - the server app in Phoenix form</li>
@@ -154,6 +154,6 @@
components. We normally recommend that people should reuse components from cornerstone as
the potential for sharing will be much higher.
</p>
-</s1>
+</section>
</body>
</document>
1.1.2.1 +9 -17 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
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-administrator.xml 12 May 2002 19:52:49 -0000 1.1
+++ guide-administrator.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,20 +1,18 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Guide - for Administrators</title>
- <authors>
- <person name="Berin Loritsch" email="bloritsch@apache.org"/>
- </authors>
+ <title>Guide - for Administrators</title>
+
+ <author name="Berin Loritsch" email="bloritsch@apache.org"/>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
- Avalon is a Server Framework that provides or will provide for
- central administration, server pooling, and quicker time to market.
- The framework defines a standard method of piecing together server
+ Avalon is a Server Framework that provides or will provide for
+ central administration, server pooling, and quicker time to market.
+ The framework defines a standard method of piecing together server
components and creating a server.
</p>
<s2 title="Target Audience">
@@ -31,12 +29,6 @@
runtime.
</p>
</s2>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:49 $
- </legal>
- </footer>
</document>
1.1.2.1 +10 -18 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
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-architecture.xml 12 May 2002 19:52:49 -0000 1.1
+++ guide-architecture.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,21 +1,19 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Guide - Architectural overview</title>
- <authors>
- <person name="Leo Simons" email="leosimons@apache.org"/>
- </authors>
+ <title>Guide - Architectural overview</title>
+
+ <author name="Leo Simons" email="leosimons@apache.org"/>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
This document briefly describes the Phoenix server architecture.
</p>
- </s1>
- <s1 title="Multiple Server Application hosting">
+ </section>
+ <section name="Multiple Server Application hosting">
<p>
Phoenix hosts one or more server applications at the same time in the same Virtual machine.
</p>
@@ -33,8 +31,8 @@
and non-existant currently at Apache is an EJB Server. This would be able to host it's own
bean applications and might use the web server for it's HTTP needs.
</p>
- </s1>
- <s1 title="Packaging of a Server Application">
+ </section>
+ <section name="Packaging of a Server Application">
<p>
Phoenix application are distriuted in a single archive.
</p>
@@ -76,12 +74,6 @@
tool for making sar files. See the "Block Developers Guide" (left
margin of this page) for more what/how/why.
</p>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:49 $
- </legal>
- </footer>
</document>
1.1.2.1 +35 -43 jakarta-avalon-phoenix/src/xdocs/guide-assemblers-creating-a-server-application.xml
Index: guide-assemblers-creating-a-server-application.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-assemblers-creating-a-server-application.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-assemblers-creating-a-server-application.xml 12 May 2002 19:52:49 -0000 1.1
+++ guide-assemblers-creating-a-server-application.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,19 +1,17 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Guide - Creating a Server Application</title>
- <authors>
+ <title>Guide - Creating a Server Application</title>
+
<person id="PD" name="Peter Donald" email="peter@apache.org"/>
- </authors>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
This document will describe the process for assembling your first Server
- Application. There is a number of steps in creating a Server Application.
+ Application. There is a number of steps in creating a Server Application.
These are;
</p>
<ol>
@@ -23,68 +21,62 @@
<li>Write the environment.xml file.</li>
<li>Package the component and related resources into a sar file.</li>
</ol>
- </s1>
- <s1 title="Select the Blocks to Assemble">
+ </section>
+ <section name="Select the Blocks to Assemble">
<p>
As a assembler it is your responsibility to select the particular Blocks
required to build your application. You may aquire the Blocks from a number
of sources depending on your resources. You may use the core Blocks supplied
with Phoenix, contract someone to build the component or download the Block
- from an online repository.
+ from an online repository.
</p>
- </s1>
- <s1 title="Write the config.xml file">
+ </section>
+ <section name="Write the config.xml file">
<p>
Configuration data for blocks is stored in the config.xml file.
- For more detail on the format of config.xml see the
- <link href="reference-config-xml-specification.html">specification</link>.
+ For more detail on the format of config.xml see the
+ <a href="reference-config-xml-specification.html">specification</a>.
</p>
- </s1>
- <s1 title="Write the assembly.xml file">
+ </section>
+ <section name="Write the assembly.xml file">
<p>
- The next stage is to write the assembly.xml file. The assembly.xml specifies
- the instances of Blocks that are part of the Server Application. Each
- Block has a name. Each block may also have dependencies that need to be
+ The next stage is to write the assembly.xml file. The assembly.xml specifies
+ the instances of Blocks that are part of the Server Application. Each
+ Block has a name. Each block may also have dependencies that need to be
satisfied and this can be done via the 'provide' sub-elements. The
provide element maps block instances from the Server Application namespace
- to the Block role namespace specified in BlockInfo files. For more detail
- on the format of assembly.xml see the <link href="reference-assembly-xml-specification.html">
- specification</link>.
+ to the Block role namespace specified in BlockInfo files. For more detail
+ on the format of assembly.xml see the <a href="reference-assembly-xml-specification.html">
+ specification</a>.
</p>
- </s1>
- <s1 title="Write the environment.xml file">
+ </section>
+ <section name="Write the environment.xml file">
<p>
The next stage is to write the environment.xml file. The environment.xml is used to
configure the code-based security policy, log management and thread pooling.
- For more detail on the format of environment.xml see the
- <link href="reference-environment-xml-specification.html">specification</link>.
+ For more detail on the format of environment.xml see the
+ <a href="reference-environment-xml-specification.html">specification</a>.
</p>
- </s1>
- <s1 title="Create the sar file">
+ </section>
+ <section name="Create the sar file">
<p>
The sar file format is the standard distribution format of Phoenix Server
- Applications. It is a standard Jar file with a specific directory layout.
- The config.xml, environment.xml and assembly.xml file must be stored in
+ Applications. It is a standard Jar file with a specific directory layout.
+ The config.xml, environment.xml and assembly.xml file must be stored in
<code>SAR-INF/</code> directory of the archive. All jar files, including
both those that contain blocks and those that contain support classes
should be stored in the <code>SAR-INF/lib/</code> directory.
</p>
- </s1>
- <s1 title="Guide Contents">
+ </section>
+ <section name="Guide Contents">
<ol>
- <li><link href="guide-assemblers-what-is-a-server-application.html">What is a Server Application?</link></li>
+ <li><a href="guide-assemblers-what-is-a-server-application.html">What is a Server Application?</a></li>
<li>How do I create a Server Application?</li>
- <li><link href="reference-config-xml-specification.html">config.xml specification</link></li>
- <li><link href="reference-assembly-xml-specification.html">assembly.xml specification</link></li>
- <li><link href="reference-environment-xml-specification.html">environment.xml specification</link></li>
+ <li><a href="reference-config-xml-specification.html">config.xml specification</a></li>
+ <li><a href="reference-assembly-xml-specification.html">assembly.xml specification</a></li>
+ <li><a href="reference-environment-xml-specification.html">environment.xml specification</a></li>
</ol>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:49 $
- </legal>
- </footer>
</document>
1.1.2.1 +17 -25 jakarta-avalon-phoenix/src/xdocs/guide-assemblers-what-is-a-server-application.xml
Index: guide-assemblers-what-is-a-server-application.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-assemblers-what-is-a-server-application.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-assemblers-what-is-a-server-application.xml 12 May 2002 19:52:49 -0000 1.1
+++ guide-assemblers-what-is-a-server-application.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,47 +1,39 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Guide - What is a Server Application?</title>
- <authors>
+ <title>Guide - What is a Server Application?</title>
+
<person id="PD" name="Peter Donald" email="peter@apache.org"/>
<person id="BL" name="Berin Loritsch" email="bloritsch@apache.org"/>
- </authors>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
In Phoenix, a Server Application is a set of Blocks that act in concert
- to provide a unified user service. Example Server Applications include a Mail
- Server, File Server, Web Server etc. The Server Application is a high level
+ to provide a unified user service. Example Server Applications include a Mail
+ Server, File Server, Web Server etc. The Server Application is a high level
component that contains a set of Block components.
</p>
<p>
- A Server Application requires a number of components other than Blocks to
- be complete. A Server Application requires configuration files to define
+ A Server Application requires a number of components other than Blocks to
+ be complete. A Server Application requires configuration files to define
Server Application wide settings (threading, security, logging), to define
- how blocks are wired together, and to define configuration data for the
- Block instances. A Block can also require other resources that are
+ how blocks are wired together, and to define configuration data for the
+ Block instances. A Block can also require other resources that are
application specific.
</p>
- </s1>
- <s1 title="Guide Contents">
+ </section>
+ <section name="Guide Contents">
<ol>
<li>What is a Server Application?</li>
- <li><link href="guide-assemblers-creating-a-server-application.html">How do I create a Server Application?</link></li>
- <li><link href="reference-config-xml-specification.html">config.xml specification</link></li>
- <li><link href="reference-assembly-xml-specification.html">assembly.xml specification</link></li>
- <li><link href="reference-environment-xml-specification.html">environment.xml specification</link></li>
+ <li><a href="guide-assemblers-creating-a-server-application.html">How do I create a Server Application?</a></li>
+ <li><a href="reference-config-xml-specification.html">config.xml specification</a></li>
+ <li><a href="reference-assembly-xml-specification.html">assembly.xml specification</a></li>
+ <li><a href="reference-environment-xml-specification.html">environment.xml specification</a></li>
</ol>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:49 $
- </legal>
- </footer>
</document>
1.1.2.1 +15 -23 jakarta-avalon-phoenix/src/xdocs/guide-assemblers.xml
Index: guide-assemblers.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-assemblers.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-assemblers.xml 12 May 2002 19:52:49 -0000 1.1
+++ guide-assemblers.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,16 +1,14 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Guide - for Server Assemblers</title>
- <authors>
- <person name="Avalon Documentation Team" email="avalon-dev@jakarta.apache.org"/>
- </authors>
+ <title>Guide - for Server Assemblers</title>
+
+ <author name="Avalon Documentation Team" email="avalon-dev@jakarta.apache.org"/>
+
</header>
<body>
- <s1 title="Who Should Read This Book?">
+ <section name="Who Should Read This Book?">
<p>
The Server Assemblers Guide is written for assemblers who want to assemble a
Server Application for Phoenix. It is assumed that you are familiar with
@@ -21,27 +19,21 @@
java programming. It does however assume you are familiar with server
fundamentals, basic security measures, and performance tuning.
</p>
- </s1>
- <s1 title="Organization">
+ </section>
+ <section name="Organization">
<p>
The information is organized into sections detailing a specifc aspect of
assembling ServerApplications.
</p>
- </s1>
- <s1 title="Contents">
+ </section>
+ <section name="Contents">
<ol>
- <li><link href="guide-assemblers-what-is-a-server-application.html">What is a Server Application?</link></li>
- <li><link href="guide-assemblers-creating-a-server-application.html">How do I create a Server Application?</link></li>
- <li><link href="reference-config-xml-specification.html">config.xml specification</link></li>
- <li><link href="reference-assembly-xml-specification.html">assembly.xml specification</link></li>
- <li><link href="reference-environment-xml-specification.html">environment.xml specification</link></li>
+ <li><a href="guide-assemblers-what-is-a-server-application.html">What is a Server Application?</a></li>
+ <li><a href="guide-assemblers-creating-a-server-application.html">How do I create a Server Application?</a></li>
+ <li><a href="reference-config-xml-specification.html">config.xml specification</a></li>
+ <li><a href="reference-assembly-xml-specification.html">assembly.xml specification</a></li>
+ <li><a href="reference-environment-xml-specification.html">environment.xml specification</a></li>
</ol>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:49 $
- </legal>
- </footer>
</document>
1.1.2.1 +31 -39 jakarta-avalon-phoenix/src/xdocs/guide-block-developers-creating-a-block.xml
Index: guide-block-developers-creating-a-block.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-block-developers-creating-a-block.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-block-developers-creating-a-block.xml 12 May 2002 19:52:49 -0000 1.1
+++ guide-block-developers-creating-a-block.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,19 +1,17 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Guide - Creating a Block</title>
- <authors>
+ <title>Guide - Creating a Block</title>
+
<person id="PD" name="Peter Donald" email="peter@apache.org"/>
- </authors>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
- This document will describe the process for creating your first block. There
- are essentially three steps that must be completed before your block is ready
+ This document will describe the process for creating your first block. There
+ are essentially three steps that must be completed before your block is ready
for assembling.
</p>
<ol>
@@ -21,40 +19,40 @@
<li>Write the BlockInfo meta-info description file.</li>
<li>Package the component and related resources into a block jar file.</li>
</ol>
- </s1>
- <s1 title="Writing the Block component">
+ </section>
+ <section name="Writing the Block component">
<p>
Writing the Block is the main task you will be called to do. It follows all
- the rules of writing a standard Avalon component. Block writers must also
- extend the <code>org.apache.phoenix.Block</code> interface.
+ the rules of writing a standard Avalon component. Block writers must also
+ extend the <code>org.apache.phoenix.Block</code> interface.
</p>
<p>
If a block implements the Composer interface it will be passed an instance
of <code>org.apache.phoenix.BlockContext</code> which is an extended version
- of <code>org.apache.avalon.Context</code>. Other than this minor change the
- Block's container (the Phoenix Kernel) supports all the Avalon lifecycle
- methods or will in the near future (at the moment suspend/resume is not yet
+ of <code>org.apache.avalon.Context</code>. Other than this minor change the
+ Block's container (the Phoenix Kernel) supports all the Avalon lifecycle
+ methods or will in the near future (at the moment suspend/resume is not yet
supported).
</p>
<p>
The block can implement an instance of <code>org.apache.phoenix.Service</code>
- if it wishes to export a service to external blocks. It is also possible to
+ if it wishes to export a service to external blocks. It is also possible to
aquire services from other blocks in the <code>compose()</code> method.
</p>
- </s1>
- <s1 title="Write the BlockInfo">
+ </section>
+ <section name="Write the BlockInfo">
<p>
- You must create this file to indicate which services this Block depends upon
- and those services which it offers. It is more fully documented in the
- <link href="reference-blockinfo-specification.html">BlockInfo Specification</link> document.
+ You must create this file to indicate which services this Block depends upon
+ and those services which it offers. It is more fully documented in the
+ <a href="reference-blockinfo-specification.html">BlockInfo Specification</a> document.
</p>
- </s1>
- <s1 title="Create the jar package">
+ </section>
+ <section name="Create the jar package">
<p>
The final step is packaging up the implementation files, BlockInfos and other
- resources into a jar file. The jar file is a standard jar file with special manifest
+ resources into a jar file. The jar file is a standard jar file with special manifest
entries. For each Block that is included in the jar, a new manifest attribute
- must be added, namely "Avalon-Block: true". An example manifest file is
+ must be added, namely "Avalon-Block: true". An example manifest file is
displayed below.
</p>
<source>
@@ -64,22 +62,16 @@
Name: com/biz/cornerstone/blocks/MyBlock.class
Avalon-Block: true
</source>
- </s1>
- <s1 title="Guide Contents">
+ </section>
+ <section name="Guide Contents">
<ol>
- <li><link href="guide-block-developers-what-is-a-block.html">What is a block?</link></li>
- <li><link href="guide-block-developers-what-is-a-block-listener.html">What is a block listener?</link></li>
- <li><link href="guide-block-developers-what-is-an-application-listener.html">What is an application listener?</link></li>
+ <li><a href="guide-block-developers-what-is-a-block.html">What is a block?</a></li>
+ <li><a href="guide-block-developers-what-is-a-block-listener.html">What is a block listener?</a></li>
+ <li><a href="guide-block-developers-what-is-an-application-listener.html">What is an application listener?</a></li>
<li>How do I create a block?</li>
- <li><link href="guide-block-developers-making-phoenix-compatible-comps.html">How do I make my components phoenix-compatible?</link></li>
- <li><link href="reference-blockinfo-specification.html">BlockInfo specification</link></li>
+ <li><a href="guide-block-developers-making-phoenix-compatible-comps.html">How do I make my components phoenix-compatible?</a></li>
+ <li><a href="reference-blockinfo-specification.html">BlockInfo specification</a></li>
</ol>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:49 $
- </legal>
- </footer>
</document>
1.1.2.1 +30 -38 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
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-block-developers-making-phoenix-compatible-comps.xml 12 May 2002 19:52:49 -0000 1.1
+++ guide-block-developers-making-phoenix-compatible-comps.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,48 +1,46 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Guide - Making components that are Phoenix compatible</title>
- <authors>
- <person name="Paul Hammant" email="hammant@apache.org"/>
- </authors>
+ <title>Guide - Making components that are Phoenix compatible</title>
+
+ <author name="Paul Hammant" email="hammant@apache.org"/>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
- Quite often reusable components are made elsewhere. Apache has a number
+ 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
</p>
- </s1>
- <s1 title="Things to remember">
+ </section>
+ <section name="Things to remember">
<p>
- There are a number of common sense things to remember when making or
+ 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">
+ <s2 title="Beanification">
<p>
<ul>
<li>Have a public empty constructor for your main class</li>
<li>Have setters for its configuration.</li>
<li>Do not assume that the File is where dependancies are - people may reuse this in jars, applets etc.</li>
- <li>Divorce your main method (if appl) from your main class - Phoenix does not call main methods.</li>
- <li>Consider that the setup and initialization of the bean does not happen in the
- constructor - as a convenience to the user, have an initialize() method</li>
- <li>If the comp has start/stop functinality consider having start() and stop() methods.</li>
+ <li>Divorce your main method (if appl) from your main class - Phoenix does not call main methods.</li>
+ <li>Consider that the setup and initialization of the bean does not happen in the
+ constructor - as a convenience to the user, have an initialize() method</li>
+ <li>If the comp has start/stop functinality consider having start() and stop() methods.</li>
<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>
<s2 title="Inversion of Control Pattern">
- 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.
+ 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">
<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>.
+ 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
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
@@ -64,8 +62,8 @@
.. might be useful. Just because you can only see a ServerSocket interface does not mean that others do.
</p>
</s2>
- </s1>
- <s1 title="Example compatible comp">
+ </section>
+ <section name="Example compatible comp">
<p>
Below are an interface and implemmentation that are suitably separated, are beanlike and is in accordance
with the IoC pattern...
@@ -180,8 +178,8 @@
}
</source>
</p>
- </s1>
- <s1 title="Misconceptions">
+ </section>
+ <section name="Misconceptions">
<p>
The following are worth stating:
<ul>
@@ -190,22 +188,16 @@
<li>Being Phoenix compatible can be for tools that are intended for client-side as well as server use.</li>
</ul>
</p>
- </s1>
- <s1 title="Guide Contents">
+ </section>
+ <section name="Guide Contents">
<ol>
- <li><link href="guide-block-developers-what-is-a-block.html">What is a block?</link></li>
- <li><link href="guide-block-developers-what-is-a-block-listener.html">What is a block listener?</link></li>
- <li><link href="guide-block-developers-what-is-an-application-listener.html">What is an application listener?</link></li>
- <li><link href="guide-block-developers-creating-a-block.html">How do I create a block?</link></li>
+ <li><a href="guide-block-developers-what-is-a-block.html">What is a block?</a></li>
+ <li><a href="guide-block-developers-what-is-a-block-listener.html">What is a block listener?</a></li>
+ <li><a href="guide-block-developers-what-is-an-application-listener.html">What is an application listener?</a></li>
+ <li><a href="guide-block-developers-creating-a-block.html">How do I create a block?</a></li>
<li>How do I make my components phoenix-compatible?</li>
- <li><link href="reference-blockinfo-specification.html">BlockInfo specification</link></li>
+ <li><a href="reference-blockinfo-specification.html">BlockInfo specification</a></li>
</ol>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:49 $
- </legal>
- </footer>
</document>
1.1.2.1 +34 -42 jakarta-avalon-phoenix/src/xdocs/guide-block-developers-what-is-a-block-listener.xml
Index: guide-block-developers-what-is-a-block-listener.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-block-developers-what-is-a-block-listener.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-block-developers-what-is-a-block-listener.xml 12 May 2002 19:52:49 -0000 1.1
+++ guide-block-developers-what-is-a-block-listener.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,76 +1,68 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Guide - What is a Block Listener?</title>
- <authors>
+ <title>Guide - What is a Block Listener?</title>
+
<person id="PD" name="Peter Donald" email="peter@apache.org"/>
- <person id="PH" name="Paul Hammant" email="Paul_Hammant@yahoo.com"/>
- </authors>
+ <person id="PH" name="Paul Hammant" email="Paul_Hammant@yahoo.com"/>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
- A Phoenix Application consists of Blocks. Blocks can depend on the
+ A Phoenix Application consists of Blocks. Blocks can depend on the
services of other Blocks. However there is circumstances in which
- relationships between Blocks other than dependency relationships
+ relationships between Blocks other than dependency relationships
should exist in an application.
</p>
<p>
For example, you may have a Block that is capable of exporting
- other Blocks as SOAP services. The Blocks that wish to be exported
+ other Blocks as SOAP services. The Blocks that wish to be exported
as SOAP services may need to export a service interface that extends
- SOAPClient.
+ SOAPClient.
</p>
- </s1>
- <s1 title="What is a Block Listener?">
+ </section>
+ <section name="What is a Block Listener?">
<p>
- A BlockListener is a component that is created before any Blocks are
+ A BlockListener is a component that is created before any Blocks are
created in an Application. It receives notification after each Block
- is created and setup for Application. The listener also receives
+ is created and setup for Application. The listener also receives
notification when a Block is about to be shutdown.
</p>
- <p>
+ <p>
The relationship discussed above (between SOAPServer and SOAPClients)
- could be modelled as dependencies but that would mean that each application
- would need to modify the SOAPServer so that it depended on a particular
- number of SOAPClients that was specific to application. A better approach
- to modelling these relationships would be to use a BlockListener to "wire"
- together the SOAPClient services in Blocks to the SOAPServer service. As
+ could be modelled as dependencies but that would mean that each application
+ would need to modify the SOAPServer so that it depended on a particular
+ number of SOAPClients that was specific to application. A better approach
+ to modelling these relationships would be to use a BlockListener to "wire"
+ together the SOAPClient services in Blocks to the SOAPServer service. As
soon as any Block is detected that implements a SOAPClient service it could
be registered with the SOAPServer.
</p>
- </s1>
- <s1 title="How to make a block listener">
+ </section>
+ <section name="How to make a block listener">
<p>
- Like normal blocks, a block listener can be <em>LogEnabled</em> and take
- configuration via <em>Configurable</em>. The special feature is that it
+ Like normal blocks, a block listener can be <em>LogEnabled</em> and take
+ configuration via <em>Configurable</em>. The special feature is that it
must implement <em>BlockListener</em> and the four methods that are a
- consequence of that. Those methods illustrate blocks being added and
- removed etc and come with a <em>BlockEvent</em> argument. The following
+ consequence of that. Those methods illustrate blocks being added and
+ removed etc and come with a <em>BlockEvent</em> argument. The following
section in assembly.xml causes instantiation of the block listener:
</p>
<source>
- <listener class="pkg.MyBlockListener" name="a-suitable-name" />
+ <listener class="pkg.MyBlockListener" name="a-suitable-name" />
</source>
- </s1>
- <s1 title="Guide Contents">
+ </section>
+ <section name="Guide Contents">
<ol>
- <li><link href="guide-block-developers-what-is-a-block.html">What is a block?</link></li>
+ <li><a href="guide-block-developers-what-is-a-block.html">What is a block?</a></li>
<li>What is a block listener?</li>
- <li><link href="guide-block-developers-what-is-an-application-listener.html">What is an application listener?</link></li>
- <li><link href="guide-block-developers-creating-a-block.html">How do I create a block?</link></li>
- <li><link href="guide-block-developers-making-phoenix-compatible-comps.html">How do I make my components phoenix-compatible?</link></li>
- <li><link href="reference-blockinfo-specification.html">BlockInfo specification</link></li>
+ <li><a href="guide-block-developers-what-is-an-application-listener.html">What is an application listener?</a></li>
+ <li><a href="guide-block-developers-creating-a-block.html">How do I create a block?</a></li>
+ <li><a href="guide-block-developers-making-phoenix-compatible-comps.html">How do I make my components phoenix-compatible?</a></li>
+ <li><a href="reference-blockinfo-specification.html">BlockInfo specification</a></li>
</ol>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:49 $
- </legal>
- </footer>
</document>
1.1.2.1 +14 -22 jakarta-avalon-phoenix/src/xdocs/guide-block-developers-what-is-a-block.xml
Index: guide-block-developers-what-is-a-block.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-block-developers-what-is-a-block.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-block-developers-what-is-a-block.xml 12 May 2002 19:52:49 -0000 1.1
+++ guide-block-developers-what-is-a-block.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,16 +1,14 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Guide - What is a Block?</title>
- <authors>
+ <title>Guide - What is a Block?</title>
+
<person id="FB" name="Federico Barbieri" email="fede@apache.org"/>
- </authors>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>In Avalon Phoenix, there are three component layers:</p>
<ul>
<li>Blocks</li>
@@ -26,30 +24,24 @@
of scale in this analogy don't hold to software (a component will
not have millions of classes).
</p>
- </s1>
- <s1 title="What is a Block?">
+ </section>
+ <section name="What is a Block?">
<p>
A Block is a Component on a larger scale. It is usually the
implementation of a Service. Examples of Blocks are
"Persistent Object Store", "Connection Pools", "XML Database",
"Authenticator" and so on.
</p>
- </s1>
- <s1 title="Guide Contents">
+ </section>
+ <section name="Guide Contents">
<ol>
<li>What is a block?</li>
- <li><link href="guide-block-developers-what-is-a-block-listener.html">What is a block listener?</link></li>
- <li><link href="guide-block-developers-what-is-an-application-listener.html">What is an application listener?</link></li>
- <li><link href="guide-block-developers-creating-a-block.html">How do I create a block?</link></li>
- <li><link href="guide-block-developers-making-phoenix-compatible-comps.html">How do I make my components phoenix-compatible?</link></li>
- <li><link href="reference-blockinfo-specification.html">BlockInfo specification</link></li>
+ <li><a href="guide-block-developers-what-is-a-block-listener.html">What is a block listener?</a></li>
+ <li><a href="guide-block-developers-what-is-an-application-listener.html">What is an application listener?</a></li>
+ <li><a href="guide-block-developers-creating-a-block.html">How do I create a block?</a></li>
+ <li><a href="guide-block-developers-making-phoenix-compatible-comps.html">How do I make my components phoenix-compatible?</a></li>
+ <li><a href="reference-blockinfo-specification.html">BlockInfo specification</a></li>
</ol>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:49 $
- </legal>
- </footer>
</document>
1.1.2.1 +16 -24 jakarta-avalon-phoenix/src/xdocs/guide-block-developers-what-is-an-application-listener.xml
Index: guide-block-developers-what-is-an-application-listener.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-block-developers-what-is-an-application-listener.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-block-developers-what-is-an-application-listener.xml 12 May 2002 19:52:49 -0000 1.1
+++ guide-block-developers-what-is-an-application-listener.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,31 +1,29 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Guide - What is an Application Listener?</title>
- <authors>
+ <title>Guide - What is an Application Listener?</title>
+
<person id="PH" name="Paul Hammant" email="Paul_Hammant@yahoo.com"/>
- </authors>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
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
</p>
- </s1>
- <s1 title="Events notified">
+ </section>
+ <section name="Events notified">
<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.
</p>
- </s1>
- <s1 title="How to make a block listener">
+ </section>
+ <section name="How to make a block listener">
<p>
Like normal blocks, an application listener can be <em>LogEnabled</em>
and take configuration via <em>Configurable</em>. The special feature
@@ -38,22 +36,16 @@
<source>
<listener class="pkg.MyApplicationListener" name="a-suitable-name" />
</source>
- </s1>
- <s1 title="Guide Contents">
+ </section>
+ <section name="Guide Contents">
<ol>
- <li><link href="guide-block-developers-what-is-a-block.html">What is a block?</link></li>
- <li><link href="guide-block-developers-what-is-a-block-listener.html">What is a block listener?</link></li>
+ <li><a href="guide-block-developers-what-is-a-block.html">What is a block?</a></li>
+ <li><a href="guide-block-developers-what-is-a-block-listener.html">What is a block listener?</a></li>
<li>What is an application listener?</li>
- <li><link href="guide-block-developers-creating-a-block.html">How do I create a block?</link></li>
- <li><link href="guide-block-developers-making-phoenix-compatible-comps.html">How do I make my components phoenix-compatible?</link></li>
- <li><link href="reference-blockinfo-specification.html">BlockInfo specification</link></li>
+ <li><a href="guide-block-developers-creating-a-block.html">How do I create a block?</a></li>
+ <li><a href="guide-block-developers-making-phoenix-compatible-comps.html">How do I make my components phoenix-compatible?</a></li>
+ <li><a href="reference-blockinfo-specification.html">BlockInfo specification</a></li>
</ol>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:49 $
- </legal>
- </footer>
</document>
1.1.2.1 +20 -28 jakarta-avalon-phoenix/src/xdocs/guide-block-developers.xml
Index: guide-block-developers.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-block-developers.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-block-developers.xml 12 May 2002 19:52:50 -0000 1.1
+++ guide-block-developers.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,13 +1,11 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Guide - for Block Developers</title>
- <authors>
- <person name="Berin Loritsch" email="bloritsch@apache.org"/>
- </authors>
+ <title>Guide - for Block Developers</title>
+
+ <author name="Berin Loritsch" email="bloritsch@apache.org"/>
+
<abstract>
The Block Developer's Guide (BDG) is written to bring an overview
of how to create and deploy a Block. The Block is the component that
@@ -15,44 +13,38 @@
</abstract>
</header>
<body>
- <s1 title="Who Should Read This Book?">
+ <section name="Who Should Read This Book?">
<p>The BDG is written for developers who want to create
- blocks for Phoenix. It is assumed that you are familiar with Java, XML, Avalon
- patterns and server side security issues. This book provides an overview of
+ blocks for Phoenix. It is assumed that you are familiar with Java, XML, Avalon
+ patterns and server side security issues. This book provides an overview of
the underlying technology, Java classes and interfaces, component model, and
behavior of server Blocks within Phoenix.</p>
<p>While this book concentrates on server fundamentals, it should not
- be construed as a “dummy's” book. Server side programming
+ be construed as a “dummy's“ book. Server side programming
is complex because of the performance and security issues you must
balance.</p>
<p>You should be well versed in the Java language and have some
practical experience developing server solutions. If you need a stronger
background on server side programming, I suggest finding a good book on the
- subject (any suggestions?).</p>
- </s1>
- <s1 title="Organization">
+ subject (any suggestions?).</p>
+ </section>
+ <section name="Organization">
<p>
Here is how the information is presented. The first few chapters are
foundational material, and describe the basic concepts you can use in your
own blocks. The later chapters specify in detail the formal requirements of
Block implementations.
</p>
- </s1>
- <s1 title="Contents">
+ </section>
+ <section name="Contents">
<ol>
- <li><link href="guide-block-developers-what-is-a-block.html">What is a block?</link></li>
- <li><link href="guide-block-developers-what-is-a-block-listener.html">What is a block listener?</link></li>
- <li><link href="guide-block-developers-what-is-an-application-listener.html">What is an application listener?</link></li>
- <li><link href="guide-block-developers-creating-a-block.html">How do I create a block?</link></li>
- <li><link href="guide-block-developers-making-phoenix-compatible-comps.html">How do I make my components phoenix-compatible?</link></li>
- <li><link href="reference-blockinfo-specification.html">BlockInfo specification</link></li>
+ <li><a href="guide-block-developers-what-is-a-block.html">What is a block?</a></li>
+ <li><a href="guide-block-developers-what-is-a-block-listener.html">What is a block listener?</a></li>
+ <li><a href="guide-block-developers-what-is-an-application-listener.html">What is an application listener?</a></li>
+ <li><a href="guide-block-developers-creating-a-block.html">How do I create a block?</a></li>
+ <li><a href="guide-block-developers-making-phoenix-compatible-comps.html">How do I make my components phoenix-compatible?</a></li>
+ <li><a href="reference-blockinfo-specification.html">BlockInfo specification</a></li>
</ol>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:50 $
- </legal>
- </footer>
</document>
1.1.2.1 +10 -18 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
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-deployers.xml 12 May 2002 19:52:50 -0000 1.1
+++ guide-deployers.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,35 +1,27 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Guide - for Deployers</title>
- <authors>
- <person name="Peter Donald" email="peter@apache.org"/>
- </authors>
+ <title>Guide - for Deployers</title>
+
+ <author name="Peter Donald" email="peter@apache.org"/>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
- Currently deploying a server application under Phoenix is simply a matter
+ Currently deploying a server application under Phoenix is simply a matter
of dropping the .sar file into the appropriate directory (<code>apps/</code>)
- and restarting Phoenix. In the future there will be more advanced methods
+ 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">
<p>
- This documentation describes the methods through which you can deploy
- Server Applications under the Phoenix kernel. It will be expanded as
+ 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>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:50 $
- </legal>
- </footer>
</document>
1.1.2.1 +28 -36 jakarta-avalon-phoenix/src/xdocs/guide-example-configuration.xml
Index: guide-example-configuration.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-example-configuration.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-example-configuration.xml 12 May 2002 19:52:50 -0000 1.1
+++ guide-example-configuration.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,17 +1,15 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Guide - Example Configuration</title>
- <authors>
- <person name="Stephen McConnell" email="mcconnell@osm.net"/>
- <person name="Gerhard Froehlich" email="g-froehlich@gmx.de"/>
- </authors>
+ <title>Guide - Example Configuration</title>
+
+ <author name="Stephen McConnell" email="mcconnell@osm.net"/>
+ <author name="Gerhard Froehlich" email="g-froehlich@gmx.de"/>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>This page contains a real production example of a block
assembly and block .xinfo description based an extract from
a B2B Enterprise Integration and Collaboration Platform developed by
@@ -19,8 +17,8 @@
<p>This example was originally a Mailing List response to a
some user questions!</p>
<p>The orginal post was written by Stephen McConnell from OSM.</p>
- </s1>
- <s1 title="The example">
+ </section>
+ <section name="The example">
<p>First we start with a manifest file in a jar the contains
a block. The manifest contains the declaration of the path
to the block implementation. This path is also used to
@@ -71,14 +69,14 @@
dependency example there are seven "service" dependencies (i.e. 7 versioned
interface dependencies that must be fulfilled for this block to function.
-->
-
+
<dependencies>
<!--
- Each dependency contains a declaration of a role name and a service
- interface and a version that can fulfil that role. The dependency
+ Each dependency contains a declaration of a role name and a service
+ interface and a version that can fulfil that role. The dependency
does not say anything about where that service implementation should
- come from (that's the job the assembly.xml file). The role element
- is simply the label used in the implementation of your block configure
+ come from (that's the job the assembly.xml file). The role element
+ is simply the label used in the implementation of your block configure
method that distinguishes a particular instance of the service.
-->
<dependency>
@@ -137,15 +135,15 @@
]]>
</source>
<p>Next is the block declaration (an extract from an <code>assembly.xml</code>
- file). This enables the declaration of WHERE the services are coming from.
+ file). This enables the declaration of WHERE the services are coming from.
I.e. you may have a system with many blocks and even the potential for matching
- services available from more that one block. The class attribute provides the
- link to the <code>.xinfo</code> file and the implementation class. The name
- is used a key within the <code>assembly.xml</code> file when wiring things together.
- E.g. the provide element references a block by its name - and declares that the
- named block will serve as the provider of the service. The role attribute matches
- the role element in the <code>.xinfo</code> dependency declaration.</p>
- The name attribute also serves a the key to lookup a configuration element in
+ services available from more that one block. The class attribute provides the
+ link to the <code>.xinfo</code> file and the implementation class. The name
+ is used a key within the <code>assembly.xml</code> file when wiring things together.
+ E.g. the provide element references a block by its name - and declares that the
+ named block will serve as the provider of the service. The role attribute matches
+ the role element in the <code>.xinfo</code> dependency declaration.</p>
+ The name attribute also serves a the key to lookup a configuration element in
the application configuration.xml file.
<source><![CDATA[
<?xml version="1.0"?>
@@ -170,18 +168,18 @@
</assembly>
]]>
</source>
- <s1/>
+ <section/>
- <s1 title="Why this seperation?"/>
+ <section name="Why this seperation?"/>
<ul>
<li>It forces structure and separation</li>
- <li>It provides a way of managing possibly multiple versions of the
+ <li>It provides a way of managing possibly multiple versions of the
same interface in a single environment</li>
<li>It enables explicit declaration of the source of service provision</li>
</ul>
-
- <p>For example you can have multiple blocks providing a TimeService.
- One of those blocks uses an external time reference while the others
+
+ <p>For example you can have multiple blocks providing a TimeService.
+ One of those blocks uses an external time reference while the others
use a local time reference. The local time block
declare dependencies on the external source time block and is periodically
synchronised. In this example all of the TimeService services are exposing
@@ -189,13 +187,7 @@
which service is the provider to another can be explicitly controlled.
While the time example is perhaps trivial, there are significant policy
security implications related to service provider selection.</p>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:50 $
- </legal>
- </footer>
</document>
1.1.2.1 +19 -26 jakarta-avalon-phoenix/src/xdocs/guide-roles.xml
Index: guide-roles.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/guide-roles.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- guide-roles.xml 12 May 2002 19:52:50 -0000 1.1
+++ guide-roles.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,16 +1,14 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Reference - Development Roles</title>
- <authors>
- <person name="Leo Simons" email="leosimons@apache.org"/>
- </authors>
+ <title>Reference - Development Roles</title>
+
+ <author name="Leo Simons" email="leosimons@apache.org"/>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
In phoenix-based development, we identify several roles. Each of these has its own
guide. If you plan to aid in the development of phoenix itself, or if you are
@@ -18,38 +16,33 @@
should be able to learn everything you need to know from the guide that fits your
role.
</p>
- </s1>
- <s1 title="The Administrator">
+ </section>
+ <section name="The Administrator">
<p>The administrator is responsible for getting phoenix to run and for keeping it
running. He typically controls the startup and shutdown of the standalone server
or daemon, and uses a management console to keep the server in top condition.</p>
- <p><link href="guide-administrator.html">Administrator's Guide</link></p>
- </s1>
- <s1 title="The Deployer">
+ <p><a href="guide-administrator.html">Administrator's Guide</a></p>
+ </section>
+ <section name="The Deployer">
<p>The deployer manages (un/re)deployment of the applications hosted withing phoenix,
typically through a management console. In real life, this is often the same person
as the adminstrator.</p>
- <p><link href="guide-deployer.html">Deployer's Guide</link></p>
- </s1>
- <s1 title="The Assembler">
+ <p><a href="guide-deployer.html">Deployer's Guide</a></p>
+
+ </section>
+ <section name="The Assembler">
<p>The assembler takes pre-written blocks and glues these together to create a
server application. Assemblers usually work closely with block developers.</p>
- <p><link href="guide-assemblers.html">Assembler Guide</link></p>
- </s1>
- <s1 title="The Block Developer">
+ <p><a href="guide-assemblers.html">Assembler Guide</a></p>
+ </section>
+ <section name="The Block Developer">
<p>The block developer creates reusable components (called blocks) that can be
wired together to form a server applications.</p>
- <p><link href="guide-block-developers.html">Block Developers Guide</link></p>
- </s1>
+ <p><a href="guide-block-developers.html">Block Developers Guide</a></p>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:50 $
- </legal>
- </footer>
</document>
1.7.2.1 +21 -32 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
retrieving revision 1.7.2.1
diff -u -r1.7 -r1.7.2.1
--- index.xml 12 May 2002 19:52:49 -0000 1.7
+++ index.xml 21 May 2002 11:58:19 -0000 1.7.2.1
@@ -1,18 +1,13 @@
<?xml version="1.0"?>
-
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Overview</title>
- <authors>
- <person name="Berin Loritsch" email="bloritsch@apache.org"/>
- <person name="Peter Donald" email="peter@apache.org"/>
- <person name="Paul Hammant" email="Paul_Hammant@yahoo.com"/>
- </authors>
+ <title>Overview</title>
+ <author name="Berin Loritsch" email="bloritsch@apache.org"/>
+ <author name="Peter Donald" email="peter@apache.org"/>
+ <author name="Paul Hammant" email="Paul_Hammant@yahoo.com"/>
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
Phoenix is a micro-kernel designed and implemented on top of the Avalon
framework. It is both an API to program to and a reference implementation.
@@ -23,16 +18,16 @@
server pools, and other facilities aimed at reducing the time to market. The API
defines a standard method of piecing togther server components and creating a server.
</p>
- </s1>
- <s1 title="Documentation is coming">
+ </section>
+ <section name="Documentation is coming">
<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
problem, please don't hesitate to contact us through the mailing list. Thank
you.
</p>
- </s1>
- <s1 title="Guide to Avalon Phoenix">
+ </section>
+ <section name="Guide to Avalon Phoenix">
<p>
This guide starts with an architectural overview of Phoenix. Then, we identify
the different roles that typically exist in daily use of phoenix. For each of
@@ -53,28 +48,22 @@
</s2>
<s2 title="Contents">
<ol>
- <li><link href="guide-architecture.html">Architectural overview</link></li>
- <li><link href="guide-roles.html">Development roles</link></li>
- <li><link href="guide-administrators.html">Administrator Guide</link></li>
- <li><link href="guide-deployers.html">Application Deployer Guide</link></li>
- <li><link href="guide-assembler.html">Server Application Assembler Guide</link></li>
- <li><link href="guide-block-developers.html">Block Developer Guide</link></li>
- <li><link href="guide-example-configuration.html">Example Configuration.</link></li>
+ <li><a href="guide-architecture.html">Architectural overview</a></li>
+ <li><a href="guide-roles.html">Development roles</a></li>
+ <li><a href="guide-administrators.html">Administrator Guide</a></li>
+ <li><a href="guide-deployers.html">Application Deployer Guide</a></li>
+ <li><a href="guide-assembler.html">Server Application Assembler Guide</a></li>
+ <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>
- </s1>
- <s1 title="Avalon Phoenix Reference Documentation">
+ </section>
+ <section name="Avalon Phoenix Reference Documentation">
<p>
Besides the
- <link href="api/index.html">Javadocs</link>, we have the
- <link href="guide-architecture.html">Architectural overview</link> to look at.
+ <a href="api/index.html">Javadocs</a>, we have the
+ <a href="guide-architecture.html">Architectural overview</a> to look at.
</p>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.7 $ $Date: 2002/05/12 19:52:49 $
- </legal>
- </footer>
</document>
1.5.2.1 +18 -20 jakarta-avalon-phoenix/src/xdocs/install.xml
Index: install.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/install.xml,v
retrieving revision 1.5
retrieving revision 1.5.2.1
diff -u -r1.5 -r1.5.2.1
--- install.xml 12 May 2002 19:52:49 -0000 1.5
+++ install.xml 21 May 2002 11:58:19 -0000 1.5.2.1
@@ -1,49 +1,47 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Installation</title>
- <authors>
- <person name="Avalon Documentation Team" email="avalon-dev@jakarta.apache.org"/>
- </authors>
+ <title>Installation</title>
+
+ <author name="Avalon Documentation Team" email="avalon-dev@jakarta.apache.org"/>
+
</header>
<body>
-<s1 title="Installation">
+<section name="Installation">
<p>
Phoenix runs on a variety of platforms that have installed the Java 2 Virtual Machine.
</p>
<p>
- Everything required to run Phoenix and develope 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>
- or from the <link href="http://jakarta.apache.org/builds/avalon/nightly/">nightly
- builds</link>.
+ Everything required to run Phoenix and develope Phoenix based products comes with the
+ <a href="http://jakarta.apache.org/builds/avalon/release">distribution</a>. If
+ you wish to help develop Avalon/Phoenix then it is recomended that you obtain the full
+ source tree from <a href="http://jakarta.apache.org/getinvolved/cvsindex.html">CVS</a>
+ or from the <a href="http://jakarta.apache.org/builds/avalon/nightly/">nightly
+ builds</a>.
</p>
-</s1>
+</section>
-<s1 title="Compiling">
+<section name="Compiling">
<p>
- Execute the relevant platform specific script (build.[sh|bat]) in the base phoenix
- directory.
-</p>
+ Execute the relevant platform specific script (build.[sh|bat]) in the base phoenix
+ directory.
+</p>
<p>
Executing this script will create a <em>dist</em> directory within the Phoenix
- directory. The <em>dist</em> directory will contain the
+ directory. The <em>dist</em> directory will contain the
compiled class files packaged into jars.
</p>
-</s1>
+</section>
</body>
</document>
1.1.2.1 +13 -21 jakarta-avalon-phoenix/src/xdocs/reference-assembly-xml-specification.xml
Index: reference-assembly-xml-specification.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/reference-assembly-xml-specification.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- reference-assembly-xml-specification.xml 12 May 2002 19:52:50 -0000 1.1
+++ reference-assembly-xml-specification.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,22 +1,20 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Reference - Specification of assembly.xml </title>
- <authors>
+ <title>Reference - Specification of assembly.xml </title>
+
<person id="PD" name="Peter Donald" email="peter@apache.org"/>
- </authors>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
The purpose of the <code>assembly.xml</code> file is to define how the Server
Application is assembled from it's component Blocks. This requires naming each
block, specifying the implementation class for each block and wiring together
blocks. The wiring is done via provides elements. Each provide element maps a
- block instance to a role of a dependency specified in the BlockInfo file. See
+ block instance to a role of a dependency specified in the BlockInfo file. See
below for a sample assembly.xml file.
</p>
<p>
@@ -25,40 +23,34 @@
a classname.
</p>
<p>
- In previous versions of Phoenix, configuration data was also stored in the
+ In previous versions of Phoenix, configuration data was also stored in the
assembly file. This is no longer the case (It is now stored in config.xml).
</p>
- </s1>
- <s1 title="Sample assembly.xml file">
+ </section>
+ <section name="Sample assembly.xml file">
<source><![CDATA[
<?xml version="1.0"?>
<assembly>
- <block-listener name="myListener"
+ <block-listener name="myListener"
class="com.biz.cornerstone.listeners.MyListener">
</block-listener>
- <block name="myAuthorizer"
+ <block name="myAuthorizer"
class="com.biz.cornerstone.blocks.MyAuthorizer">
</block>
- <block name="myBlock"
+ <block name="myBlock"
class="com.biz.cornerstone.blocks.MyBlock">
- <provide name="myAuthorizer"
+ <provide name="myAuthorizer"
role="com.biz.cornerstone.services.Authorizer"/>
</block>
</assembly>]]>
</source>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:50 $
- </legal>
- </footer>
</document>
1.1.2.1 +17 -25 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
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- reference-blockinfo-specification.xml 12 May 2002 19:52:50 -0000 1.1
+++ reference-blockinfo-specification.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,20 +1,18 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Reference - The BlockInfo Specification</title>
+ <title>Reference - The BlockInfo Specification</title>
<version>3.0</version>
- <authors>
+
<person id="PD" name="Peter Donald" email="peter@apache.org"/>
- </authors>
+
<abstract>
Specifies the format of BlockInfo files and the reasons for particular aspects.
</abstract>
</header>
<body>
- <s1 title="Block Metadata">
+ <section name="Block Metadata">
<p>
The meta-data about each block is stored in a BlockInfo file. The info
includes details on what version the block is, what <code>Service</code>s
@@ -24,8 +22,8 @@
</p>
<p>
- The BlockInfo file has the same name as the Block except with the extention
- <code>.xinfo</code>. Thus if you were looking up the meta info for a block named
+ The BlockInfo file has the same name as the Block except with the extention
+ <code>.xinfo</code>. Thus if you were looking up the meta info for a block named
<code>com.biz.cornerstone.blocks.MyBlock</code> you would look up the resource
<code>com/biz/cornerstone/blocks/MyBlock.xinfo</code> in the same block jar file that
the block was packaged in. The BlockInfo file is a simple XML format. An
@@ -43,20 +41,20 @@
</block>
<services>
- <service name="com.biz.cornerstone.services.MyService"
+ <service name="com.biz.cornerstone.services.MyService"
version="2.1.3" />
</services>
<dependencies>
<dependency>
<role>com.biz.cornerstone.services.Authorizer</role>
- <service name="com.biz.cornerstone.service.Authorizer"
+ <service name="com.biz.cornerstone.service.Authorizer"
version="1.0"/>
</dependency>
<dependency>
<!-- note that role is not specified and defaults
to name of service -->
- <service name="com.biz.cornerstone.service.RoleMapper"
+ <service name="com.biz.cornerstone.service.RoleMapper"
version="1.0"/>
</dependency>
</dependencies>
@@ -66,13 +64,13 @@
]]>
</source>
<p>
- You will notice that the information in the BlockInfo file is separated into
+ You will notice that the information in the BlockInfo file is separated into
three main sections; <code>block</code>, <code>services</code> and
- <code>dependencies</code>.
+ <code>dependencies</code>.
</p>
- <s2 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
+ <s2 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">
@@ -84,20 +82,14 @@
<s2 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
- <link href="@FRAMEWORK_BASE@/guide-cop-in-avalon.html">components</link> section, the
+ specified by the <code>role</code> element of dependency. As is documented in the
+ <a href="@FRAMEWORK_BASE@/guide-cop-in-avalon.html">components</a> section, the
concept of Role is more than just a behavioural contract. A <code>Service</code> is
a behavioural contract and thus the necessity to support the role element. In most
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>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:50 $
- </legal>
- </footer>
</document>
1.1.2.1 +8 -16 jakarta-avalon-phoenix/src/xdocs/reference-config-xml-specification.xml
Index: reference-config-xml-specification.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/reference-config-xml-specification.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- reference-config-xml-specification.xml 12 May 2002 19:52:50 -0000 1.1
+++ reference-config-xml-specification.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,26 +1,24 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Reference - Specification of config.xml </title>
- <authors>
+ <title>Reference - Specification of config.xml </title>
+
<person id="PD" name="Peter Donald" email="peter@apache.org"/>
- </authors>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
The purpose of the <code>config.xml</code> file is to provide configuration data
- to each of the blocks that require configuration data. The format of the
+ to each of the blocks that require configuration data. The format of the
configuration data is block-specific, thus refer to documentation of Block
for relevant details. Each element below the root element has a name coresponding
to the name of a block specified in assembly.xml file. The contents of this
element is the configuration data for the block.
</p>
- </s1>
- <s1 title="Sample config.xml file">
+ </section>
+ <section name="Sample config.xml file">
<source><![CDATA[
<?xml version="1.0"?>
@@ -39,13 +37,7 @@
</config>]]>
</source>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:50 $
- </legal>
- </footer>
</document>
1.1.2.1 +10 -18 jakarta-avalon-phoenix/src/xdocs/reference-environment-xml-specification.xml
Index: reference-environment-xml-specification.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-phoenix/src/xdocs/reference-environment-xml-specification.xml,v
retrieving revision 1.1
retrieving revision 1.1.2.1
diff -u -r1.1 -r1.1.2.1
--- reference-environment-xml-specification.xml 12 May 2002 19:52:50 -0000 1.1
+++ reference-environment-xml-specification.xml 21 May 2002 11:58:19 -0000 1.1.2.1
@@ -1,16 +1,14 @@
<?xml version="1.0"?>
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
<header>
- <title>Avalon Phoenix - Reference - Specification of environment.xml</title>
- <authors>
+ <title>Reference - Specification of environment.xml</title>
+
<person id="PD" name="Peter Donald" email="peter@apache.org"/>
- </authors>
+
</header>
<body>
- <s1 title="Introduction">
+ <section name="Introduction">
<p>
The purpose of the <code>environment.xml</code> file is to configure environmental
or Server Application wide settings. Currently this means being able to set the
@@ -19,8 +17,8 @@
section but this has been deprecated. Note that previously the information stored in
<code>environment.xml</code> was stored in a file named <code>server.xml</code>.
</p>
- </s1>
- <s1 title="Sample environment.xml file">
+ </section>
+ <section name="Sample environment.xml file">
<source><![CDATA[
<?xml version="1.0"?>
@@ -103,23 +101,17 @@
<targets>
<file id="default">
- <filename>${app.home}/logs/default-</filename>
+ <filename>{app.home}/logs/default-</filename">
<append>true</append>
<rotation type="unique" pattern="yyyyMMdd" suffix=".log">
<date>yyyyMMdd</date>
</rotation>
</file>
</targets>
-</logger>
-]]></source>
+</logger>]]>
+</source>
</p>
- </s1>
+ </section>
</body>
- <footer>
- <legal>
- Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
- $Revision: 1.1 $ $Date: 2002/05/12 19:52:50 $
- </legal>
- </footer>
</document>
No revision
No revision
1.1.2.1 +70 -0 jakarta-avalon-phoenix/src/xdocs/images/Attic/header.gif
<<Binary file>>
No revision
No revision
1.1.2.1 +92 -0 jakarta-avalon-phoenix/src/xdocs/stylesheets/Attic/docs.vsl
1.1.2.1 +48 -0 jakarta-avalon-phoenix/src/xdocs/stylesheets/Attic/project.xml
1.1.2.1 +208 -0 jakarta-avalon-phoenix/src/xdocs/stylesheets/Attic/templates.vm
1.1.2.1 +2 -0 jakarta-avalon-phoenix/src/xdocs/stylesheets/Attic/velocity.properties
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>