mcconnell 2002/08/06 00:32:24
Modified: assembly/src/xdocs activation.xml assembly.xml classpath.xml
containers.xml dictionary.xml export.xml
extensions.xml faq.xml install.xml list.xml
logging.xml support.xml
Log:
General documentation updating spelling, etc.
Revision Changes Path
1.2 +5 -3
jakarta-avalon-excalibur/assembly/src/xdocs/activation.xml
Index: activation.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/activation.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- activation.xml 21 Jul 2002 05:04:10 -0000 1.1
+++ activation.xml 6 Aug 2002 07:32:23 -0000 1.2
@@ -14,14 +14,14 @@
</section>
<section name="Startup">
<p>
-On invocation of startup at the kernel level, the root container is started,
resulting in the assessment of each profile. If the profile is declared with
the activate attribute as TRUE, Merlin will invoke instantiation of the service
during the startup phase. Instantation will be following by startup of the
component at which time the compoennt instance will be supplied with a service
manager (or component manager). Service to which the target component is
dependent will not be activated until the target invokes lookup on the supplied
service manager. Merlin's service/compoennt manager implemetation holds
refeences to the resource and as such, can instantiate services on demand - or
not at all if the dependent service is not required within a particular session.
+On invocation of startup at the kernel level, the root container is started,
resulting in the assessment of each profile. If the profile is declared with
the activate attribute as TRUE, Merlin will invoke instantiation of the service
during the startup phase. Instantiation will be following by startup of the
component at which time the component instance will be supplied with a service
manager (or component manager). Service to which the target component is
dependent will not be activated until the target invokes lookup on the supplied
service manager. Merlin's service/component manager implementation holds
references to the resource and as such, can instantiate services on demand - or
not at all if the dependent service is not required within a particular session.
</p>
<p>If no components request explicit activation, Merlin will simply continue
with a normal shutdown process.
</p>
</section>
<section name="Shutdown">
<p>
-Shutdown is normally initiated by the kernel resulting in the orderly
shutdown of running services followed by shutdown of the container hierachy.
Shutdown signals both the halting of execution of a service and the disposal of
service and container resources.
+Shutdown is normally initiated by the kernel resulting in the orderly
shutdown of running services followed by shutdown of the container hierarchy.
Shutdown signals both the halting of execution of a service and the disposal of
service and container resources.
</p>
</section>
@@ -34,6 +34,8 @@
</footer>
</document>
+
+
1.4 +13 -11 jakarta-avalon-excalibur/assembly/src/xdocs/assembly.xml
Index: assembly.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/assembly.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- assembly.xml 2 Aug 2002 09:34:56 -0000 1.3
+++ assembly.xml 6 Aug 2002 07:32:23 -0000 1.4
@@ -74,7 +74,7 @@
services it is dependent on.
--></i></font>
-<component-info>
+<type>
<font color="gray"><i><!--
@@ -175,12 +175,12 @@
<font color="gray"><i><!--
- Declaration of the set of dependecies that this component type has on
+ Declaration of the set of dependencies that this component type has on
component suppliers. Dependency declarations define the role name
that the component will use to access a service via a service
or component manager. The service element identifies a service
- descriptor that is publised by a potential supplier component.
- A dependecy may be declared as optional by setting the optional
+ descriptor that is published by a potential supplier component.
+ A dependency may be declared as optional by setting the optional
attribute value to TRUE. The default value for optional is FALSE.
--></i></font>
@@ -189,7 +189,7 @@
<font color="gray"><i><!--
A dependecy declaration. In the following example the optional
attribute is redundant as it is equivalent to the default value
- but is included here for completness.
+ but is included here for completeness.
--></i></font>
<dependency optional="<font color="darkred">FALSE</font>">
@@ -233,7 +233,7 @@
A phase declares the lifecycle phase interface implement by this
component type
under the <reference> element. A phase declaration may also
include an
<attributes> declaration. Phase handlers (extensions) will be
applied in
- the same order as the declarations appear here - and will be
deomissioning in
+ the same order as the declarations appear here - and will be
decommissioned in
reverse order.
--></i></font>
@@ -272,7 +272,7 @@
</extensions>
- </component-info>
+ </type>
</pre>
@@ -313,7 +313,7 @@
Apply the following configuration when instantiating the component.
This configuration
will be applied as the primary configuration in a cascading
configuration chain. A
type may declare a default configuration under a "classname".xconfig
file that will be
- used to dereference any configuration requests not resolvable by the
configuration
+ used to de-reference any configuration requests not resolvable by
the configuration
supplied here.
--></i></font>
@@ -322,7 +322,7 @@
</configuration>
<font color="gray"><i><!--
- The parameterization criteria from this instance of the component
type.
+ The parameterisation criteria from this instance of the component
type.
--></i></font>
<parameters/>
@@ -335,7 +335,7 @@
<ul>
<li>a classname declared as a value of the dependency attribute
"avalon.service.selector"</li>
<li>a class named <dependent-service-classname>Selector within the
classpath</li>
- <li>the default merlin service selector implemetation</li>
+ <li>the default Merlin service selector implementation</li>
</ul>
</p>
<p>
@@ -362,6 +362,8 @@
</footer>
</document>
+
+
1.2 +48 -4 jakarta-avalon-excalibur/assembly/src/xdocs/classpath.xml
Index: classpath.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/classpath.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- classpath.xml 21 Jul 2002 05:04:10 -0000 1.1
+++ classpath.xml 6 Aug 2002 07:32:23 -0000 1.2
@@ -6,8 +6,49 @@
<author email="[EMAIL PROTECTED]">Stephen McConnell</author>
</properties>
<body>
- <section name="Classpath Managment">
-<p>A classpath declaration may occur at kernel and container scope. A
kernel classpath is accessible by the root container and all subsidary
containers. A classpath declared at container scope is accesible only to the
immediate container in which the claspath is defined and its subsidiary
containers. An example of a classpath declaration is included below.</p>
+ <section name="ClassLoader Management">
+
+ <p>Merlin provides two structures supporting the deinition of the class
available with the kernel and containers.</p>
+ <ul>
+ <li><a href="#extensions">Extensions</a> - declaration of a set of
extension directories in which extension jar files are located</li>
+ <li><a href="#classpath">Classpath</a> - declaration of classpath
strcutures that may be included within kernel or container scope.</li>
+ </ul>
+
+ <subsection name="Extensions Sub-System">
+<a href="extension"/>
+<p>A kernel may contain a single extensions element that declares the
directories in which extension jar files may be located. Extensions are
available to the root classloader and as such are available to all containers.
An example of an extensions declaration is included below.</p>
+
+
+<pre>
+ <kernel>
+</pre>
+
+<p><font color="gray"><i><!--
+Declaration of possibly multiple extension directories. The extensions
element may contain multiple directory-set declarations, each containing
possible multiple relative directory paths. On initialisation, the kernel
classloader will be established with references to the supplied directories.
Merlin will attempt to resolve any jar files declaring extension dependencies
based on the jar files included in the declared extension directories.
+--></i></font></p>
+
+<pre>
+ <extensions">
+ <dirset dir="<font color="darkred">.</font>">
+ <include name="<font color="darkred">dist</font>"/>
+ <include name="<font color="darkred">lib</font>"/>
+ </dirset>
+ </extensions">
+</pre>
+
+ <p><font color="gray"><i><!--
+ Other kernel declarations.
+ --></i></font></p>
+
+<pre>
+ </kernel>
+</pre>
+
+ </subsection>
+
+ <subsection name="Classpath Managment">
+<a href="extension"/>
+<p>A classpath declaration may occur at kernel and container scope. A
kernel classpath is accessible by the root container and all subsidiary
containers. A classpath declared at container scope is accessible only to the
immediate container in which the classpath is defined and its subsidiary
containers. An example of a classpath declaration is included below.</p>
<pre>
<kernel>
@@ -55,7 +96,8 @@
</kernel>
</pre>
- </section>
+ </subsection>
+ </section>
</body>
<footer>
<legal>
@@ -65,5 +107,7 @@
</footer>
</document>
+
+
1.2 +6 -4
jakarta-avalon-excalibur/assembly/src/xdocs/containers.xml
Index: containers.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/containers.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- containers.xml 17 Jul 2002 13:48:37 -0000 1.1
+++ containers.xml 6 Aug 2002 07:32:23 -0000 1.2
@@ -10,15 +10,15 @@
<section name="Container">
<p>The Merlin system provides support for a cascading containers. This
model enables component assemblers to associate jar files under a protected
container scope where each container is associated with its own classloader.</p>
- <p>Merlin will handle resolution of service dependencies for
components contained in containers by looking for explicitly declared
components commencing within the local container, and working progressively up
the container hierachy. If no explict solutions are resolved, Merlin will
attempt to build an implicit solution based on components declared in the
respective container classpath declarations.</p>
+ <p>Merlin will handle resolution of service dependencies for
components contained in containers by looking for explicitly declared
components commencing within the local container, and working progressively up
the container hierarchy. If no explicit solutions are resolved, Merlin will
attempt to build an implicit solution based on components declared in the
respective container classpath declarations.</p>
</section>
<section name="Container Model">
- <p>A new container is created using a container model. The model is
the defintion of the container, its classpath, and the profiles of the
components it is resposible for managing. Container models are declared
programatically or via an XML description.</p>
+ <p>A new container is created using a container model. The model is
the defintion of the container, its classpath, and the profiles of the
components it is responsible for managing. Container models are declared
programmatically or via an XML description.</p>
- <p><i>Minimilist container defintion.</i></p>
+ <p><i>Minimilist container definition.</i></p>
<pre>
<container name="<font color="darkred">root</font>">
<classpath>
@@ -42,3 +42,5 @@
</footer>
</document>
+
+
1.2 +5 -4
jakarta-avalon-excalibur/assembly/src/xdocs/dictionary.xml
Index: dictionary.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/dictionary.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- dictionary.xml 6 Aug 2002 04:10:38 -0000 1.1
+++ dictionary.xml 6 Aug 2002 07:32:23 -0000 1.2
@@ -17,7 +17,7 @@
<td><a href="assembly"/><p>Assembly</p></td>
<td>
<p>The recursive process of the resolution of dependencies declared by a
component with services provided by other components.</p>
-<p>Merlin provides substantial support for the automation of component
assembly. Under a kernel configuration a user can declare explicit components
to be assembled. Merlin will attempt to put together solutions for component
dependencies (service depedencies ad extension dependecies) based on the
availability of other explicit component declarations together with implicit
and packaged component declarations. Implicit components are derived from the
manifest declarations within the jar files containing Packaged components are
based on a <classname>.xprofile resource packaged with a component
type.</p>
+<p>Merlin provides substantial support for the automation of component
assembly. Under a kernel configuration a user can declare explicit components
to be assembled. Merlin will attempt to put together solutions for component
dependencies (service dependencies and lifecycle extension dependencies) based
on the availability of other explicit component declarations together with
implicit and packaged component declarations. Implicit components are derived
from the manifest declarations within the jar files containing Packaged
components are based on a <classname>.xprofile resource packaged with a
component type.</p>
</td>
</tr>
<tr>
@@ -45,7 +45,7 @@
<td><a href="phase"/><p>Profile</p></td>
<td>
<p>A <a
href="api/assembly/org/apache/excalibur/merlin/model/Profile.html">Profile</a>
is a description of a component <a
href="api/meta/org/apache/excalibur/meta/info/Type.html">Type</a> instantiation
criteria.</p>
-<p>A type may have many differnet instantionation crieria - differented in
terms of the context, parameters, or configuration to be applied. Profiles
within Merlin may be qualifed in terms of the statup policy and enabled status.
Startup policy inidicates that a component shall be started on startup of the
container or if activation of the component can be deferred until it is
requered. Profile enablement policy simply declares if a profile is enabled or
not - non enabled component profiles will not be included as assembly
candidates.</p>
+<p>A type may have many different instantiation criteria - different in
terms of the context, parameters, or configuration to be applied. Profiles
within Merlin may be qualified in terms of the startup policy and enabled
status. Startup policy indicates that a component shall be started on startup
of the container or if activation of the component can be deferred until it is
required. Profile ennoblement policy simply declares if a profile is enabled
or not - non enabled component profiles will not be included as assembly
candidates.</p>
</td>
</tr>
<tr>
@@ -66,4 +66,5 @@
</legal>
</footer>
-</document>
\ No newline at end of file
+</document>
+
1.2 +4 -2 jakarta-avalon-excalibur/assembly/src/xdocs/export.xml
Index: export.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/export.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- export.xml 21 Jul 2002 05:04:10 -0000 1.1
+++ export.xml 6 Aug 2002 07:32:23 -0000 1.2
@@ -8,7 +8,7 @@
<body>
<section name="Service Export">
<p>
-A Merlin kernel can be considered as a dynamic type in that it can export
services depending on the configuration it is supplied with. The services
established by a kernel are refered to as "exported" services. Exported
service are encapsulated within ResourceDesignator and as such, the client of a
exported service is not aware of the instantiated state of the service. Client
applications the utilise the exported service should contain to reference the
ResourceDesignator instance in prefernece to actual service instantiation where
possible. For example, a server managing a collection of process process types
could use a kernel to establish the process component resources from which it
could publish available processes. On reception of a client request for
activation of a process, the server could establish a new process and apply a
service manager that maintains the resource reference. This ensures that
services are only instantiated when actually needed.
+A Merlin kernel can be considered as a dynamic type in that it can export
services depending on the configuration it is supplied with. The services
established by a kernel are referred to as "exported" services. Exported
services are encapsulated within ResourceDesignator and as such, the client of
an exported service is not aware of the instantiated state of the service.
Client applications utilise the exported service should contain to reference
the ResourceDesignator instance in preference to actual service instantiation
where possible. For example, a server managing a collection of process types
could use a kernel to establish the process component resources from which it
could publish available processes. On reception of a client request for
activation of a process, the server could establish a new process and apply a
service manager that maintains the resource reference. This ensures that
services are only instantiated when actually needed.
</p>
</section>
</body>
@@ -20,5 +20,7 @@
</footer>
</document>
+
+
1.2 +58 -22
jakarta-avalon-excalibur/assembly/src/xdocs/extensions.xml
Index: extensions.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/extensions.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- extensions.xml 21 Jul 2002 05:04:10 -0000 1.1
+++ extensions.xml 6 Aug 2002 07:32:23 -0000 1.2
@@ -2,37 +2,71 @@
<document>
<properties>
- <title>Extensions</title>
+ <title>Lifecycle Extensions</title>
<author email="[EMAIL PROTECTED]">Stephen McConnell</author>
</properties>
<body>
- <section name="Extensions Sub-System">
-<p>A kernel may contain a single extensions element that declares the
directories in which extension jar files may be located. Extensions are
available to the root classloader and as such are available to all containers.
An example of an extensions declaration is included below.</p>
+ <section name="Lifecycle Extensions">
+<p>Merlin provides support for pluggable lifecycle extensions. Components
can declare dependencies on a lifecycle extension provider under the component
type declaration using the <phases/> element. Component can declare
themselves as providers of lifecycle extension services via the
<extensions/> element.</p>
+
+<p>The following XML type declaration depicts a component that declares a
dependency on two lifecycle phase extensions (Securable and Persistable) and in
addition, declares itself as a provider of lifecycle extension handling for the
phase interface DemoExtension.</p>
<pre>
- <kernel>
-</pre>
+ <type>
-<p><font color="gray"><i><!--
-Declaration of possibly multiple extension directories. The extensions
element may contain multiple directory-set declations, each containing possible
multiple relative directory paths. On initialization, the kernal classloader
wil be established with references to the supplied directories. Merlin will
attempt to resolve any jar files declaring extension dependecies based on the
jar files included in the declared extension directories.
---></i></font></p>
+ <component>
+ <name><font color="darkred">my-component</font></name>
+ <version><font color="darkred">1.2.1</font></version>
+ </component>
+
+ <phases>
+
+ <font color="gray"><i><!--
+ A phase declares a lifecycle phase interface implement by this
component type
+ under the <reference> element. A phase declaration may also
include an
+ <attributes> declaration. Phase handlers (extensions) will be
applied to
+ this component in the same order as the declarations appear here.
During
+ component decommissioning the phase order will be reversed.
+ --></i></font>
+
+ <phase>
+ <reference type="<font
color="darkred">org.apache.security.Securable</font>"/>
+ </phase>
+ <phase>
+ <reference type="<font
color="darkred">org.apache.db.Persistable</font>"/>
+ </phase>
+
+ </phases>
+
+ <font color="gray"><i><!--
+ Components may optionally declare their ability to provide extension
handling. An
+ extension is equivalent to a phase handler.
+ --></i></font>
+
+ <extensions>
+
+ <font color="gray"><i><!--
+ If a component type declares an extension, the component
implementation
+ MUST implement the <a
href="api/assembly/org/apache/excalibur/merlin/assembly/resource/Extension.html">Extension</a>
interface.
+ Possible stage attributes values include CREATE, DESTROY, ACCESS,
RELEASE,
+ INNER, OUTER and ALL. The INNER attribute value is equivalent to both
+ ACCESS and RELEASE. The OUTER attribute value is equivalent to CREATE
and
+ DESTORY. The ALL value is equivalent to both INNER and OUTER.
+ --></i></font>
+
+ <extension stage="ALL">
+ <reference type="<font
color="darkred">org.apache.excalibur.playground.DemoExtension</font>"/>
+ <attributes>
+ <attribute key="<font color="darkred">status</font>"
value="<font color="darkred">experimental</font>"/>
+ </attributes>
-<pre>
- <extensions">
- <dirset dir="<font color="darkred">.</font>">
- <include name="<font color="darkred">dist</font>"/>
- <include name="<font color="darkred">lib</font>"/>
- </dirset>
- </extensions">
-</pre>
+ </extension>
- <p><font color="gray"><i><!--
- Other kernel declarations.
- --></i></font></p>
+ </extensions>
+
+ </type>
-<pre>
- </kernel>
</pre>
</section>
@@ -45,5 +79,7 @@
</footer>
</document>
+
+
1.4 +6 -4 jakarta-avalon-excalibur/assembly/src/xdocs/faq.xml
Index: faq.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/faq.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- faq.xml 2 Aug 2002 09:34:56 -0000 1.3
+++ faq.xml 6 Aug 2002 07:32:23 -0000 1.4
@@ -19,16 +19,16 @@
<subsection name="What's the difference between Merlin and Phoenix?">
-<p>Merlin and Phoenix can be considered to be derived from the same family
in terms of architecture and notions of "what a component is". Both Merlin and
Phoenix leverage meta-information about a type of component (the .xinfo
resource). Meta information used by Phoenix is described as a <block>
whereas Merlin uses the more general <component-info> model. Both models
are relatively equivalent and it is expected that Phoenix will be migrating to
a common <component-info> schema in the near future. With this in place,
Phoenix based components will be usable within Merlin providing the compoennts
do not use Phoenix specific interfaces or classes. Typically, the two aspect
to watch for on Phoenix based components that limit portability are (a)
references to the class BlockContext (which can be eliminated by using the
context key instead of Phoenix specific context accessors), and (b), the usage
of the BlockListener and ApplicationListener interfaces (both representing
Phoenix specific extensions).</p>
+<p>Merlin and Phoenix can be considered to be derived from the same family
in terms of architecture and notions of "what a component is". Both Merlin and
Phoenix leverage meta-information about a type of component (the .xinfo
resource). Meta information used by Phoenix is described as a <block>
whereas Merlin uses the more general <component-info> model. Both models
are relatively equivalent and it is expected that Phoenix will be migrating to
a common <component-info> schema in the near future. With this in place,
Phoenix based components will be usable within Merlin providing the components
do not use Phoenix specific interfaces or classes. Typically, the two aspect
to watch for on Phoenix based components that limit portability are (a)
references to the class BlockContext (which can be eliminated by using the
context key instead of Phoenix specific context accessors), and (b), the usage
of the BlockListener and ApplicationListener interfaces (both representing
Phoenix specific extensions).</p>
<p>Aside from these differences, Phoenix and Merlin are very similar - they
both handle service assembly, activation, and decommissioning. Differences
appear with respect to the approaches used and the overhead implied on a user.
Merlin makes every attempt to minimise that level of information required to
assemble a service model. For example, Merlin does not require explicit
linking of components under an assembly file. Furthermore, Merlin provides a
framework for defaults management enabling automatic service establishment.
Perhaps most significant is the design objective of Merlin to provide simple
programmatic embedding of kernels and containers into other components and
foreign systems. Relative to Merlin, Phoenix is much more static in that it
requires a significantly higher level of engagement in the establishment of a
service model. On the other-hand, Phoenix contains additional features not
present in Merlin - in particular JMX support.</p>
-<p>At the overall architecture level Phonenix provides support for pluggable
facilities (cut-down components) to provide support for core servises towards a
set of applications. Merlin's goes further by providing the ability for real
"component" based facilities model via embedded <a
href="api/assembly/org/apache/excalibur/merlin/kernel/Kernel.html">kernels</a>
that export services backed by a flexible hierarchical <a
href="api/assembly/org/apache/excalibur/merlin/container/Container.html">container</a>
structure. Based simply on available functionality, Phoenix, it's the choice
when selecting an app-server. Merlin on the other-hand demands substantially
less engagement by the end-user and delivers a commensurate reduction in
support overhead.</p>
+<p>At the overall architecture level Phoenix provides support for pluggable
facilities (cut-down components) to provide support for core services towards a
set of applications. Merlin's goes further by providing the ability for real
"component" based facilities model via embedded <a
href="api/assembly/org/apache/excalibur/merlin/kernel/Kernel.html">kernels</a>
that export services backed by a flexible hierarchical <a
href="api/assembly/org/apache/excalibur/merlin/container/Container.html">container</a>
structure. Based simply on available functionality, Phoenix, it's the choice
when selecting an app-server. Merlin on the other-hand demands substantially
less engagement by the end-user and delivers a commensurate reduction in
support overhead.</p>
</subsection>
<subsection name="What's the difference between Containerkit and the
Merlin Meta-Model?">
-<p>The meta model defined in both Containerkit and Merlin separates out the
notion of type related meta-info from the criteria for instantiation - commonly
referred to a meta-data. The Merlin meta-info API is basically a superset of
the containerkit API. The Merlin meta-info model goes beyond conterkit by
providing explicit declaration of lifecycle extension depedencies, and
lifecycle extension handlers.</p>
+<p>The meta model defined in both Containerkit and Merlin separates out the
notion of type related meta-info from the criteria for instantiation - commonly
referred to a meta-data. The Merlin meta-info API is basically a superset of
the containerkit API. The Merlin meta-info model goes beyond containerkit by
providing explicit declaration of lifecycle extension dependencies, and
lifecycle extension handlers.</p>
<p>The Merlin API used more human friendly naming conventions (e.g. a type
is referred to a <a
href="api/meta/org/apache/excalibur/meta/info/Type.html">Type</a>, a component
profile at the meta-data level is called a <a
href="api/assembly/org/apache/excalibur/merlin/model/Profile.html">Profile</a>,
the association between profiles is called an <a
href="api/assembly/org/apache/excalibur/merlin/model/Association.html">Association</a>
- whereas containerkit references the same entries using more technically
oriented naming conventions - ComponentInfo, ComponentMetaData and
DependencyMetaData respectively). Aside from naming conventions, the Merlin
meta-info model includes a method through which a client can assess a default
configuration associated and packaged with the type, allows dynamic addition of
association, and includes support for formal lifecycle extension management.</p>
@@ -48,6 +48,8 @@
</footer>
</document>
+
+
1.3 +6 -4 jakarta-avalon-excalibur/assembly/src/xdocs/install.xml
Index: install.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/install.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- install.xml 2 Aug 2002 09:34:56 -0000 1.2
+++ install.xml 6 Aug 2002 07:32:23 -0000 1.3
@@ -8,9 +8,9 @@
<body>
<section name="Installation">
- <subsection name="Dependecies">
+ <subsection name="Dependencies">
<p>
-Installation of Merlin assumes you have Ant 1.4 or later installled on you
machine.
+Installation of Merlin assumes you have Ant 1.4 or later installed on you
machine.
</p>
<p><a href="http://jakarta.apache.org/ant/index.html";>Ant Home Page</a></p>
@@ -18,7 +18,7 @@
<subsection name="CVS Repository">
<p>
-The Merlin distribution is available via the Apache CVS server. To access
the server, simply use the following commands (if you are using a GUI CVS
client, configure it appropriatly):
+The Merlin distribution is available via the Apache CVS server. To access
the server, simply use the following commands (if you are using a GUI CVS
client, configure it appropriately):
</p>
<pre>
@@ -61,5 +61,7 @@
</footer>
</document>
+
+
1.2 +2 -3 jakarta-avalon-excalibur/assembly/src/xdocs/list.xml
Index: list.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/list.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- list.xml 21 Jul 2002 05:04:10 -0000 1.1
+++ list.xml 6 Aug 2002 07:32:23 -0000 1.2
@@ -9,7 +9,7 @@
<section name="Mailing Lists">
<p>
-Merlin is part of the Apache Avalon Project. The <a
href="http://jakarta.apache.org/site/mail2.html#Avalon";>Avalon User list</a> is
available for general questions and queries relating to Avalon iniatives.
+Merlin is part of the Apache Avalon Project. The <a
href="http://jakarta.apache.org/site/mail2.html#Avalon";>Avalon User list</a> is
available for general questions and queries relating to Avalon initiatives.
</p>
</section>
@@ -22,5 +22,4 @@
</footer>
</document>
-
1.4 +12 -10 jakarta-avalon-excalibur/assembly/src/xdocs/logging.xml
Index: logging.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/logging.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- logging.xml 2 Aug 2002 09:34:56 -0000 1.3
+++ logging.xml 6 Aug 2002 07:32:23 -0000 1.4
@@ -8,11 +8,11 @@
<body>
<section name="Logging Sub-System">
-<p>Logging services build above the Avalon framework abstract logging
infrastructure. Merlin provides the mechanisms through which logging
hierachies can be created, logging prioprities assigned, and definition of log
event output targets. Logging directives may be includes at the kernel,
container and component levels.</p>
+<p>Logging services build above the Avalon framework abstract logging
infrastructure. Merlin provides the mechanisms through which logging
hierarchies can be created, logging priorities assigned, and definition of log
event output targets. Logging directives may be includes at the kernel,
container and component levels.</p>
</section>
<section name="Kernel Directives">
-<p>A kernel may be configured with an option logging system creation
directive. The logging element declares the application wide default logging
priority. A target element enables defintion of a logging file to which log
entries will be directed. The target name attribute is the name referenced by
category elements defined within the loggers element. Child category
declarations must include a name (the logging catagory), and may optionally
include a target and a priority attribute. The target defaults of "default"
which corresponds to a internal default logging target that issue messages to
System.out (unless overriden by a target named default). If the target is
declared inside a catagory element, it must refer to a named target element.
The priority attribute may container one of the values <code>DEBUG</code>,
<code>INFO</code>, <code>WARN</code> or <code>ERROR</code>. The target must
contain a single file element with the attribute <code>location</code> the
corresponds to the name of the logging file.</p>
+<p>A kernel may be configured with an option logging system creation
directive. The logging element declares the application wide default logging
priority. A target element enables definition of a logging file to which log
entries will be directed. The target name attribute is the name referenced by
category elements defined within the loggers element. Child category
declarations must include a name (the logging category), and may optionally
include a target and a priority attribute. The target defaults of "default"
which corresponds to a internal default logging target that issue messages to
System.out (unless overridden by a target named default). If the target is
declared inside a category element, it must refer to a named target element.
The priority attribute may container one of the values <code>DEBUG</code>,
<code>INFO</code>, <code>WARN</code> or <code>ERROR</code>. The target must
contain a single file element with the attribute <code>location</code> the
corresponds to the name of the logging file.</p>
<pre>
<kernel>
@@ -40,7 +40,7 @@
<p><font color="gray"><i><!--
Multiple categories may be declared - each category defines a priority
and target
- to be used for the respective caegory. Category names are scoped
relative to the
+ to be used for the respective category. Category names are scoped
relative to the
container. In this context the container is the kernel. As such a
category name
of "logging" translates to a full logging category path of
"kernel.logging". The
logging element may contain priority and target attribute values. These
values
@@ -74,8 +74,8 @@
<li><b>installer</b>, the classloader that handles initial model
construction</li>
<li><b>installer.types</b>, type registration</li>
<li><b>installer.types.builder</b>, type creation</li>
- <li><b>loader</b>, the classloader essigned to the kernel following
bootstrap installation</li>
- <li><b>export</b>, provides reports on the services exprted by the
kernel</li>
+ <li><b>loader</b>, the classloader assigned to the kernel following
bootstrap installation</li>
+ <li><b>export</b>, provides reports on the services exported by the
kernel</li>
</ul>
</p>
@@ -84,7 +84,7 @@
<section name="Container Directives">
- <p>A kernel contains a single root container. The name of the container
establishes a top level logging category name. Categories defined within the
scope of a container are always relative to the enclosing container path name.
For example, a logging category of "assembly" inside a root container named
"root" is definting parameters for the logging category "root.assembly".
Sub-containers within a container hierachy for a category name path. For
example, if a container name "sub" is included in a container named "root", the
containers logging category will be "root.sub". Logging category declarations
scoped within a container will be created relative to the contains rerived
category path.</p>
+ <p>A kernel contains a single root container. The name of the container
establishes a top level logging category name. Categories defined within the
scope of a container are always relative to the enclosing container path name.
For example, a logging category of "assembly" inside a root container named
"root" is defining parameters for the logging category "root.assembly".
Sub-containers within a container hierarchy for a category name path. For
example, if a container name "sub" is included in a container named "root", the
containers logging category will be "root.sub". Logging category declarations
scoped within a container will be created relative to the contains category
path.</p>
<p>Logging sub-categories within the container category include:
<ul>
@@ -93,7 +93,7 @@
<li><b>loader.types.builder</b>, type creation</li>
<li><b>assembly</b>, actions relating to auto-assembly of components</li>
<li><b>assembly.selector</b>, the service selection sub-system</li>
- <li><b>provider</b>, component resoruce provider sub-system</li>
+ <li><b>provider</b>, component resource provider sub-system</li>
<li><b>provider</b>, component lifecycle handler sub-system</li>
</ul>
</p>
@@ -105,7 +105,7 @@
<container name="<font color="darkred">root</font>">
</pre>
<p><font color="gray"><i><!--
-Multiple categories may be declared - each category defines a priority and
target to be used for the respective caegory. Category names are scoped
relative to the container. As such a category name of "logging" translates to
a full logging category path of "root.logging". The logging element may
contain priority and target attribute values. These values will overide the
system wide defaults relative to kernel sub-categories. --></i></font>
+Multiple categories may be declared - each category defines a priority and
target to be used for the respective category. Category names are scoped
relative to the container. As such a category name of "logging" translates to
a full logging category path of "root.logging". The logging element may
contain priority and target attribute values. These values will override the
system wide defaults relative to kernel sub-categories. --></i></font>
</p>
<pre>
@@ -132,7 +132,7 @@
</section>
<section name="Component Directives">
-<p>Component scoped logging directives are relative to the enclosing
componet profile declaration. The logging categories are component specific
and will normally be documeted as part of the component you are using. The
following example is the logging configuration for the demonstration component
included with the distribution.</p>
+<p>Component scoped logging directives are relative to the enclosing
component profile declaration. The logging categories are component specific
and will normally be documented as part of the component you are using. The
following example is the logging configuration for the demonstration component
included with the distribution.</p>
<pre>
<kernel>
@@ -177,5 +177,7 @@
</footer>
</document>
+
+
1.3 +5 -3 jakarta-avalon-excalibur/assembly/src/xdocs/support.xml
Index: support.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/support.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- support.xml 2 Aug 2002 09:34:56 -0000 1.2
+++ support.xml 6 Aug 2002 07:32:23 -0000 1.3
@@ -28,7 +28,7 @@
<tr valign="top" bgcolor="lightgrey">
<td class="mini">0.7</td>
<td class="mini"><a
href="http://home.osm.net/doc/collaboration/index.html";>Collaboration
Framework</a></td>
- <td class="mini">Component providing support for the execution
of collaborative business processes in which the policy concerning rights and
privaliges and the sequencing of multiple participants is declared through DPML
(Digital Product Modelling Language).</td></tr>
+ <td class="mini">Component providing support for the execution
of collaborative business processes in which the policy concerning rights and
privileges and the sequencing of multiple participants is declared through DPML
(Digital Product Modelling Language).</td></tr>
<tr valign="top" bgcolor="lightgrey">
<td class="mini">0.8</td>
<td class="mini"><a
href="http://home.osm.net/doc/community/index.html";>Community Framework</a></td>
@@ -40,7 +40,7 @@
<tr valign="top" bgcolor="lightgrey">
<td class="mini">0.9</td>
<td class="mini"><a
href="http://home.osm.net/doc/gateway/index.html";>Gateway</a></td>
- <td class="mini">Services supporting user centric web based
interaction with business processes, tasks, workspaces, and service
directories. The Gateway services defines a suite of servlet that provide a
consitent view of a user's business context, available resources, and the
characteristics, features, and policies of the resources available and in
use.</td></tr>
+ <td class="mini">Services supporting user centric web based
interaction with business processes, tasks, workspaces, and service
directories. The Gateway services defines a suite of servlet that provide a
consistent view of a user's business context, available resources, and the
characteristics, features, and policies of the resources available and in
use.</td></tr>
</table>
<p><img src="/images/nothing.gif" border="0"/></p>
</section>
@@ -53,5 +53,7 @@
</footer>
</document>
+
+
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
