donaldp 02/05/23 04:43:13
Modified: src/xdocs features.xml for-developers-a-future.xml
for-developers-project-structure.xml
getting-started.xml guide-administrator.xml
guide-architecture.xml guide-deployers.xml
guide-example-configuration.xml guide-roles.xml
index.xml install.xml
Added: src/xdocs changes.xml
src/xdocs/assemblers assembly-xml-specification.xml
config-xml-specification.xml
creating-a-server-application.xml
environment-xml-specification.xml index.xml
what-is-a-server-application.xml
src/xdocs/bdg blockinfo-specification.xml
creating-a-block.xml index.xml
making-phoenix-compatible-comps.xml
what-is-a-block-listener.xml what-is-a-block.xml
what-is-an-application-listener.xml
src/xdocs/images header.gif
src/xdocs/stylesheets changes.vsl docs.vsl project.xml
templates.vm velocity.properties
Removed: src/xdocs announcement.xml book.xml
for-developers-changes.xml for-developers-todo.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 phoenix.uris
reference-assembly-xml-specification.xml
reference-blockinfo-specification.xml
reference-config-xml-specification.xml
reference-environment-xml-specification.xml
src/xdocs/dtd changes-v10.dtd characters.ent
document-v10.dtd
Log:
Merge ANAKIA_DOCS branch into main branch.
Revision Changes Path
1.6 +12 -19 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.6
diff -u -r1.5 -r1.6
--- features.xml 12 May 2002 20:57:14 -0000 1.5
+++ features.xml 23 May 2002 11:43:12 -0000 1.6
@@ -1,43 +1,36 @@
<?xml version="1.0"?>
-
-<!DOCTYPE document SYSTEM "dtd/document-v10.dtd">
-
<document>
-
<header>
- <title>Avalon Phoenix - Features</title>
- <authors>
- <person name="Leo Simons" email="[EMAIL PROTECTED]"/>
- </authors>
+ <title>Features</title>
+ <author name="Leo Simons" email="[EMAIL PROTECTED]"/>
</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 +39,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 +63,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.2 +22 -18
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.2
diff -u -r1.1 -r1.2
--- for-developers-a-future.xml 12 May 2002 19:52:49 -0000 1.1
+++ for-developers-a-future.xml 23 May 2002 11:43:12 -0000 1.2
@@ -1,36 +1,40 @@
<?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="[EMAIL PROTECTED]"/>
- </authors>
+ <title>A future</title>
+ <author name="Paul Hammant" email="[EMAIL PROTECTED]"/>
</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.
+ 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.
+ 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.2 +9 -25
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.2
diff -u -r1.1 -r1.2
--- for-developers-project-structure.xml 12 May 2002 19:52:49 -0000
1.1
+++ for-developers-project-structure.xml 23 May 2002 11:43:12 -0000
1.2
@@ -1,22 +1,18 @@
<?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="[EMAIL PROTECTED]"/>
- </authors>
+ <title>Project Structure</title>
+ <author name="Leo Simons" email="[EMAIL PROTECTED]"/>
</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,26 +41,20 @@
|- verifier
|- xdoclet
</source>
- </s1>
- <s1 title="CVS Directory structure">
+ </section>
+ <section name="CVS Directory structure">
<source>
-jakarta-avalon
-|
-|- console : JMX-based management console
+jakarta-avalon-phoenix
|
|- lib : for third party libraries
|
|- src
| |
-| |- compat : deprecated stuff
| |- conf : jar manifest
-| |- documentation : cocoon configuration
| |- java : java sources
| |- manifest : jar manifest files
| |- pdk : sources for PDK
-| |- proposal : place for ideas to nurture
| |- schema : DTDs for XML files
-| |- scratchpad : place for nonsupported, unstable code
| |- script : shell scripts for usage in a standalone setup
| |- test : unit tests
| |- xdocs : site documentation in xml format
@@ -77,13 +67,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.5 +18 -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.5
diff -u -r1.4 -r1.5
--- getting-started.xml 12 May 2002 19:52:49 -0000 1.4
+++ getting-started.xml 23 May 2002 11:43:12 -0000 1.5
@@ -3,28 +3,26 @@
<document>
<header>
- <title>Avalon Phoenix - Getting Started</title>
- <authors>
- <person name="Avalon Documentation Team"
email="[email protected]"/>
- <person name="Leo Simons" email="[EMAIL PROTECTED]"/>
- <person name="Paul Hammant" email="[EMAIL PROTECTED]"/>
- </authors>
+ <title>Getting Started</title>
+ <author name="Avalon Documentation Team"
email="[email protected]"/>
+ <author name="Leo Simons" email="[EMAIL PROTECTED]"/>
+ <author name="Paul Hammant" email="[EMAIL PROTECTED]"/>
</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="http://jakarta.apache.org/avalon/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 +30,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 +47,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 +56,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 +96,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 +111,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 +152,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.2 +27 -38 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.2
diff -u -r1.1 -r1.2
--- guide-administrator.xml 12 May 2002 19:52:49 -0000 1.1
+++ guide-administrator.xml 23 May 2002 11:43:12 -0000 1.2
@@ -1,42 +1,31 @@
<?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="[EMAIL PROTECTED]"/>
- </authors>
- </header>
- <body>
- <s1 title="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
- components and creating a server.
- </p>
- <s2 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">
- <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>
- </s1>
- </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>
+ <header>
+ <title>Guide - for Administrators</title>
+ <author name="Berin Loritsch" email="[EMAIL PROTECTED]"/>
+ </header>
+ <body>
+ <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
+ components and creating a server.
+ </p>
+ <subsection name="Target Audience">
+ <p>
+ This documentation will describe the care and feeding of
the Avalon
+ Phoenix kernel from the point of view of the administrator.
+ </p>
+ </subsection>
+ <subsection name="Guide non-existent, but features are there">
+ <p>We currently have no info on this whatsoever. However,
this doesn't
+ mean that Phoenix is not easy to administrate - the contrary
is true,
+ since our tight integration with JMX exposes the entire
kernel at
+ runtime.
+ </p>
+ </subsection>
+ </section>
+ </body>
</document>
1.2 +81 -83 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.2
diff -u -r1.1 -r1.2
--- guide-architecture.xml 12 May 2002 19:52:49 -0000 1.1
+++ guide-architecture.xml 23 May 2002 11:43:12 -0000 1.2
@@ -1,87 +1,85 @@
<?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="[EMAIL PROTECTED]"/>
- </authors>
- </header>
- <body>
- <s1 title="Introduction">
- <p>
- This document briefly describes the Phoenix server architecture.
- </p>
- </s1>
- <s1 title="Multiple Server Application hosting">
- <p>
- Phoenix hosts one or more server applications at the same time in
the same Virtual machine.
- </p>
- <figure>
- <title>Phoenix layer diagram</title>
- <graphic srccredit="Paul Hammant, 2001"
fileref="images/phoenix-layers.jpg" format="JPEG"/>
- </figure>
- <p>
- Shown above are three hosted server applications. A mail server
that would implement
- multiple listeners for incoming and outgoing services (POP3, SMTP,
IMAP etc). Outlook,
- Eudora and other mail clients would be able to connect to the
server. As it happens,
- Apache has a project in progress called "James" that provides these
services and Newsgroups.
- Also shown is a Web server. That would respond to HTTP/HTTPS
requests from similar standards
- based clients and be able to host it's own applications (web-apps
and virtual websites). Lastly,
- 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">
- <p>
- Phoenix application are distriuted in a single archive.
- </p>
- <s2 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
- externally.
- </p>
- <figure>
- <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">
- <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
- within a directory "lib" insde the sar file). The Assembly and
configuration instructions
- are in xml form and contained within a "conf" directory inside the
sar file.
- </p>
- <figure>
- <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">
- <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.
- </p>
- <figure>
- <title>FtpServer, a real Phoenix application</title>
- <graphic srccredit="Paul Hammant, 2001"
fileref="images/phoenix-app-ftpserver.jpg" format="JPEG"/>
- </figure>
- </s2>
- <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
- margin of this page) for more what/how/why.
- </p>
- </s1>
- </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>
+ <header>
+ <title>Guide - Architectural overview</title>
+ <author name="Leo Simons" email="[EMAIL PROTECTED]"/>
+ </header>
+ <body>
+ <section name="Introduction">
+ <p>
+ This document briefly describes the Phoenix server
architecture.
+ </p>
+ </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>
+ <center>
+ <b>Phoenix layer diagram</b>
+ </center>
+ <center>
+ <img src="./images/phoenix-layers.jpg"/>
+ </center>
+ <p>
+ Shown above are three hosted server applications. A mail
server that would implement
+ multiple listeners for incoming and outgoing services (POP3,
SMTP, IMAP etc). Outlook,
+ Eudora and other mail clients would be able to connect to the
server. As it happens,
+ Apache has a project in progress called "James" that provides
these services and Newsgroups.
+ Also shown is a Web server. That would respond to HTTP/HTTPS
requests from similar standards
+ based clients and be able to host it's own applications
(web-apps and virtual websites). Lastly,
+ 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>
+ </section>
+ <section name="Packaging of a Server Application">
+ <p>
+ Phoenix application are distriuted in a single archive.
+ </p>
+ <subsection name="Packaging in terms of blocks">
+ <p>
+ Phoenix hosts server applications made up of blocks. The
blocks may depend on libraries
+ to function correctly. The blocks are tied together with
Assembly instructions and Configured
+ externally.
+ </p>
+ <center>
+ <b>Phoenix application in block view</b>
+ </center>
+ <center>
+ <img src="./images/phoenix-app-block.jpg"/>
+ </center>
+ </subsection>
+ <subsection name="Packaging in terms of block jar files">
+ <p>
+ The server application is entirely contained withing one
"sar" file. Sar is "Server ARchive".
+ Each block is a jar file. The dependant libraries are
regular jars (placed
+ within a directory "lib" insde the sar file). The
Assembly and configuration instructions
+ are in xml form and contained within a "conf" directory
inside the sar file.
+ </p>
+ <figure>
+ <title>Phoenix application in block jar view</title>
+ <center>
+ <img src="./images/phoenix-app-blockjars.jpg"/>
+ </center>
+ </figure>
+ </subsection>
+ <subsection name="FtpServer as a Phoenix application">
+ <p>
+ FtpServer (part of the Avalon/Cornerstone project) is
distributed in sar form. Here is a
+ view of it's blocks. It has no third party jars that it
depends on.
+ </p>
+ <center>
+ <b>FtpServer, a real Phoenix application</b>
+ </center>
+ <center>
+ <img src="./images/phoenix-app-ftpserver.jpg"/>
+ </center>
+ </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
+ margin of this page) for more what/how/why.
+ </p>
+ </section>
+ </body>
</document>
1.2 +10 -20 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.2
diff -u -r1.1 -r1.2
--- guide-deployers.xml 12 May 2002 19:52:50 -0000 1.1
+++ guide-deployers.xml 23 May 2002 11:43:12 -0000 1.2
@@ -1,35 +1,25 @@
<?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="[EMAIL PROTECTED]"/>
- </authors>
+ <title>Guide - for Deployers</title>
+ <author name="Peter Donald" email="[EMAIL PROTECTED]"/>
</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">
+ <subsection name="Target Audience">
<p>
- This documentation describes the methods through which you can
deploy
- Server Applications under the Phoenix kernel. It will be expanded
as
+ 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>
+ </subsection>
+ </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.2 +37 -45
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.2
diff -u -r1.1 -r1.2
--- guide-example-configuration.xml 12 May 2002 19:52:50 -0000 1.1
+++ guide-example-configuration.xml 23 May 2002 11:43:12 -0000 1.2
@@ -1,17 +1,13 @@
<?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="[EMAIL PROTECTED]"/>
- <person name="Gerhard Froehlich" email="[EMAIL PROTECTED]"/>
- </authors>
+ <title>Guide - Example Configuration</title>
+ <author name="Stephen McConnell" email="[EMAIL PROTECTED]"/>
+ <author name="Gerhard Froehlich" email="[EMAIL PROTECTED]"/>
</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 +15,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
@@ -59,7 +55,7 @@
implements these interfaces (if it doesn't then Phoenix will
terminate).
-->
- <service name="org.apache.acme.hub.gateway.FactoryService"
version="1.0" />
+ <service name="org.apache.acme.hub.gateway.FactoryService"/>
</services>
<!--
@@ -71,19 +67,19 @@
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>
<role>GATEWAY</role>
- <service name="org.apache.acme.hub.gateway.GatewayContext"
version="1.0"/>
+ <service name="org.apache.acme.hub.gateway.GatewayContext"/>
</dependency>
<!--
@@ -94,7 +90,8 @@
-->
<dependency>
<role>ORB</role>
- <service name="org.apache.acme.hub.gateway.ORBService"
version="2.4"/>
+ <service name="org.apache.acme.hub.gateway.ORBService"
+ version="2.4"/>
</dependency>
<!--
@@ -103,7 +100,7 @@
-->
<dependency>
<role>PSS</role>
- <service
name="org.apache.acme.hub.gateway.ProcessorStorageHomeService" version="1.0"/>
+ <service
name="org.apache.acme.hub.gateway.ProcessorStorageHomeService"/>
</dependency>
<!--
@@ -113,21 +110,21 @@
-->
<dependency>
<role>REGISTRY</role>
- <service name="org.apache.acme.hub.gateway.Registry"
version="1.0"/>
+ <service name="org.apache.acme.hub.gateway.Registry"/>
</dependency>
<!-- etc. -->
<dependency>
<role>DOMAIN</role>
- <service name="org.apache.acme.hub.gateway.DomainService"
version="1.0"/>
+ <service name="org.apache.acme.hub.gateway.DomainService"/>
</dependency>
<dependency>
<role>RANDOM</role>
- <service name="org.apache.acme.hub.gateway.RandomService"
version="1.0"/>
+ <service name="org.apache.acme.hub.gateway.RandomService"/>
</dependency>
<dependency>
<role>CLOCK</role>
- <service name="org.apache.acme.service.time.TimeService"
version="1.0"/>
+ <service name="org.apache.acme.service.time.TimeService"/>
</dependency>
</dependencies>
@@ -137,15 +134,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"?>
@@ -155,7 +152,8 @@
<!-- other assembly information here -->
<!-- Certification Request Processor Factory -->
- <block class="org.apache.acme.pki.process.CertificationRequestServer"
name="certification" >
+ <block class="org.apache.acme.pki.process.CertificationRequestServer"
+ name="certification" >
<provide name="gateway" role="GATEWAY"/>
<provide name="gateway" role="ORB"/>
<provide name="gateway" role="PSS"/>
@@ -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.2 +45 -49 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.2
diff -u -r1.1 -r1.2
--- guide-roles.xml 12 May 2002 19:52:50 -0000 1.1
+++ guide-roles.xml 23 May 2002 11:43:12 -0000 1.2
@@ -1,55 +1,51 @@
<?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="[EMAIL PROTECTED]"/>
- </authors>
- </header>
- <body>
- <s1 title="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
- responsible for all these aspects, you should read all the guides.
Otherwise, you
- should be able to learn everything you need to know from the guide that
fits your
- role.
- </p>
- </s1>
- <s1 title="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>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>The assembler takes pre-written blocks and glues these together to
create a
- server application. Assemblers usually work closely with block
developers.</p>
+ <header>
+ <title>Development Roles</title>
+ <author name="Leo Simons" email="[EMAIL PROTECTED]"/>
+ </header>
+ <body>
+ <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
+ responsible for all these aspects, you should read all the guides.
Otherwise, you
+ should be able to learn everything you need to know from the guide
that fits your
+ role.
+ </p>
+ </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>
+ <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-assemblers.html">Assembler Guide</link></p>
- </s1>
- <s1 title="The Block Developer">
- <p>The block developer creates reusable components (called blocks)
that can be
- wired together to form a server applications.</p>
+ <p>
+ <a href="guide-deployer.html">Deployer's Guide</a>
+ </p>
- <p><link href="guide-block-developers.html">Block Developers
Guide</link></p>
- </s1>
- </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>
+ </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>
+ <a href="assemblers/index.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>
+ <a href="bdg/index.html">Block Developers Guide</a>
+ </p>
+ </section>
+ </body>
</document>
1.8 +25 -36 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.8
diff -u -r1.7 -r1.8
--- index.xml 12 May 2002 19:52:49 -0000 1.7
+++ index.xml 23 May 2002 11:43:12 -0000 1.8
@@ -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="[EMAIL PROTECTED]"/>
- <person name="Peter Donald" email="[EMAIL PROTECTED]"/>
- <person name="Paul Hammant" email="[EMAIL PROTECTED]"/>
- </authors>
+ <title>Overview</title>
+ <author name="Berin Loritsch" email="[EMAIL PROTECTED]"/>
+ <author name="Peter Donald" email="[EMAIL PROTECTED]"/>
+ <author name="Paul Hammant" email="[EMAIL PROTECTED]"/>
</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,22 +18,22 @@
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
these, we provide a basic guide. We finish with a complete example.
</p>
- <s2 title="Target Audience">
+ <subsection name="Target Audience">
<p>
This documentation is aimed towards people who:
<ul>
@@ -50,31 +45,25 @@
<li>wish to reuse Avalon Phoenix concepts in their own
application</li>
</ul>
</p>
- </s2>
- <s2 title="Contents">
+ </subsection>
+ <subsection name="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="assemblers/index.html">Server Application Assembler
Guide</a></li>
+ <li><a href="bdg/index.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">
+ </subsection>
+ </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.6 +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.6
diff -u -r1.5 -r1.6
--- install.xml 12 May 2002 19:52:49 -0000 1.5
+++ install.xml 23 May 2002 11:43:12 -0000 1.6
@@ -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="[email protected]"/>
- </authors>
+ <title>Installation</title>
+
+ <author name="Avalon Documentation Team"
email="[email protected]"/>
+
</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.11 +29 -28 jakarta-avalon-phoenix/src/xdocs/changes.xml
1.2 +54 -0
jakarta-avalon-phoenix/src/xdocs/assemblers/assembly-xml-specification.xml
1.2 +43 -0
jakarta-avalon-phoenix/src/xdocs/assemblers/config-xml-specification.xml
1.2 +80 -0
jakarta-avalon-phoenix/src/xdocs/assemblers/creating-a-server-application.xml
1.2 +115 -0
jakarta-avalon-phoenix/src/xdocs/assemblers/environment-xml-specification.xml
1.2 +47 -0 jakarta-avalon-phoenix/src/xdocs/assemblers/index.xml
1.2 +37 -0
jakarta-avalon-phoenix/src/xdocs/assemblers/what-is-a-server-application.xml
1.2 +93 -0
jakarta-avalon-phoenix/src/xdocs/bdg/blockinfo-specification.xml
1.2 +73 -0 jakarta-avalon-phoenix/src/xdocs/bdg/creating-a-block.xml
1.2 +48 -0 jakarta-avalon-phoenix/src/xdocs/bdg/index.xml
1.2 +209 -0
jakarta-avalon-phoenix/src/xdocs/bdg/making-phoenix-compatible-comps.xml
1.2 +68 -0
jakarta-avalon-phoenix/src/xdocs/bdg/what-is-a-block-listener.xml
1.2 +47 -0 jakarta-avalon-phoenix/src/xdocs/bdg/what-is-a-block.xml
1.2 +51 -0
jakarta-avalon-phoenix/src/xdocs/bdg/what-is-an-application-listener.xml
1.2 +70 -0 jakarta-avalon-phoenix/src/xdocs/images/header.gif
<<Binary file>>
1.2 +65 -0 jakarta-avalon-phoenix/src/xdocs/stylesheets/changes.vsl
1.2 +92 -0 jakarta-avalon-phoenix/src/xdocs/stylesheets/docs.vsl
1.2 +51 -0 jakarta-avalon-phoenix/src/xdocs/stylesheets/project.xml
1.2 +214 -0 jakarta-avalon-phoenix/src/xdocs/stylesheets/templates.vm
1.2 +2 -0
jakarta-avalon-phoenix/src/xdocs/stylesheets/velocity.properties
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
![http://www.sun.com/products-n-solutions/hw/networking/images/prodsplash/x1.jpg"](http://www.sun.com/products-n-solutions/hw/networking/images/prodsplash/x1.jpg"){kind=link}