mcconnell 2002/07/20 22:04:11
Modified: assembly/src/xdocs deployment.xml
assembly/src/xdocs/stylesheets project.xml
Added: assembly/src/xdocs activation.xml assembly.xml classpath.xml
export.xml extensions.xml faq.xml install.xml
list.xml logging.xml support.xml
assembly/src/xdocs/images nothing.gif
Log:
implementation and supporting documetation
Revision Changes Path
1.3 +5 -1
jakarta-avalon-excalibur/assembly/src/xdocs/deployment.xml
Index: deployment.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/deployment.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- deployment.xml 20 Jul 2002 05:03:01 -0000 1.2
+++ deployment.xml 21 Jul 2002 05:04:10 -0000 1.3
@@ -32,6 +32,10 @@
</li>
</ul>
+ </section>
+
+ <section name="Kernel Definition">
+
<p>Components assembly requires the declaration of at least one
component with the kernel configuration profile. The profile enables the
declaration of a hierarchy of containers and component profiles within
containers. The containers within a hierarchy collaborate to resolve service
dependencies for the components they respectively manage.</p>
<p>Example components and a kernel.xml profile are included in the
distribution.</p>
1.1
jakarta-avalon-excalibur/assembly/src/xdocs/activation.xml
Index: activation.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Activation</title>
<author email="[EMAIL PROTECTED]">Stephen McConnell</author>
</properties>
<body>
<section name="Activation Framework">
<p>
On completion of service assembly phase, the assembled component profiles are
packaged as resources. Each resource is an association of the profile, a
provider (responsible for supplying context arguments, manager and so forth),
and a lifecycle helper.
</p>
</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.
</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.
</p>
</section>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
$Revision: 1.1 $ $Date: 2002/07/21 05:04:10 $
</legal>
</footer>
</document>
1.1 jakarta-avalon-excalibur/assembly/src/xdocs/assembly.xml
Index: assembly.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Assembly</title>
<author email="[EMAIL PROTECTED]">Stephen McConnell</author>
</properties>
<body>
<section name="Assembly Engine">
<p>
Merlin assembles component based on explicitly declared services together
with packaged and implicitly derived services. Explicitly declared services
include component profiles declared within a container. Packaged services
include components that are supplied with profile infomation inside its jar
file. Implicit services are derived from type information together with a
system generated minimal profile. These components are initially identified by
manifest entries that declare the components included within a jar file.
</p>
</section>
<section name="Manifest Entries">
<p>
Manifest entries are used to declare the existance of one or more component
implementations within a jar file. An example of a manifest declaration is
included here.
</p>
<pre>
Manifest-Version: 1.0
Created-By: Stephen McConnell
Extension-List: framework
framework-Extension-Name: avalon-framework
framework-Specification-Version: 1.0
framework-Implementation-Version: 4.1.2
Name: org/apache/excalibur/playground/SimpleComponent.class
Avalon-Block: true
Name: org/apache/excalibur/playground/TerminalComponent.class
Avalon-Block: true
Name: org/apache/excalibur/playground/BasicComponent.class
Avalon-Block: true
Name: org/apache/excalibur/playground/ComplexComponent.class
Avalon-Block: true
Name: org/apache/excalibur/playground/InvalidComponent.class
Avalon-Block: true
</pre>
</section>
<section name="Candidate Establishment">
<p>
Service assembly in Merlin is based on the formal declaration of dependencies
by a component type. A component type is Java class with a null constructor and
an associated <class-name>.xinfo file. The xinfo file contains an XML
description of the component. This information includes the following:
</p>
<p>
<ul>
<li>simple name</li>
<li>component type attributes</li>
<li>logging categories used by the component</li>
<li>context objects and access keys the component requires</li>
<li>service that the component is dependent on, and the role names that the
component will use to resolve them using a service or component manager</li>
<li>the service that the component provides</li>
<li>other related attributes</li>
</ul>
</p>
<p>An example of a component .xinfo resoruce is presented in the following
XML.</p>
<pre>
<font color="gray"><i><!--
Example of a component meta info external XML form.
The element contains the information required to construct an instance of
org.apache.excalibur.containerkit.metainfo.ComponentInfo. It includes
information about the component type, the service it provides, and the
services it is dependent on.
--></i></font>
<component-info>
<font color="gray"><i><!--
Defintion of a single component descriptor.
--></i></font>
<component>
<font color="gray"><i><!-- the name of the component (character
restriction appply) --></i></font>
<name><font color="darkred">my-component</font></name>
<font color="gray"><i><!-- the implementation version --></i></font>
<version><font color="darkred">1.2.1</font></version>
<font color="gray"><i><!-- the set of attribibutes associated with the
type
(attribute names and values are examples only) --></i></font>
<attributes>
<attribute key="<font
color="darkred">avalon:display-name-i18n</font>" value="<font
color="darkred">display-name</font>"/>
<attribute key="<font color="darkred">avalon:lifestyle</font>"
value="<font color="darkred">THREAD_SAFE</font>"/>
</attributes>
</component>
<font color="gray"><i><!--
The set of logging catagories the component uses.
--></i></font>
<loggers>
<logger name="store"/>
<logger name="store.cache"/>
<logger name="verifier"/>
</loggers>
<font color="gray"><i><!--
Declaration of the context constraints for the compoent type.
The "type" attribute is the name of an interface derived from the default
contenxt interface org.apache.avalon.framework.context.Context
--></i></font>
<context type="<font color="darkred">MyContextInterface</font>">
<font color="gray"><i><!--
Declaration of an entry in a context object, the "key" is
the key used by a component to locate the context entry,
the "type" is the classname of value (typically an interface)
or primative type. The default value is java.lang.String.
The "optional" attribute is a boolean value derived from the
TRUE or FALSE that indicates if the context value must be
provided or not (default is FALSE).
--></i></font>
<entry key="<font color="darkred">base</font>" type="<font
color="darkred">java.io.File</font>"/>
<entry key="<font color="darkred">mode</font>" optional="<font
color="darkred">TRUE</font>"/>
</context>
<font color="gray"><i><!--
Declaration of the set of services that this component is capable
of supplying. Each service declarared under the services element
may be referenced by other component info descriptions as a
dependecy. A container is responsible for the assemably of
components based on the connection of supply components to
consumer components via a common service description.
--></i></font>
<services>
<font color="gray"><i><!--
The service type is the classname of an interface and the
version identifier qualifes the interface version. The
default version value is 1.0.
--></i></font>
<service>
<service-ref type="<font color="darkred">SimpleService</font>"
version="<font color="darkred">3.2</font>">
<attributes>
<font color="gray"><i><!--
Service type attributes go here.
Need some relevant examples.
--></i></font>
</attributes>
</service>
</services>
<font color="gray"><i><!--
Declaration of the set of dependecies 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
attribute value to TRUE. The default value for optional is FALSE.
--></i></font>
<dependencies>
<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.
--></i></font>
<dependency optional="<font color="darkred">FALSE</font>">
<font color="gray"><i><!--
The role name that the component will use as the argument to
lookup. The default value is the value of the service type
attribute listed below.
--></i></font>
<role><font color="darkred">my-transformer</font></role>
<font color="gray"><i><!--
service reference containing the classname of the service interface
and the version value where version defaults to 1.0
--></i></font>
<service-ref type="<font
color="darkred">org.apache.cocoon.api.Transformer</font>" version="<font
color="darkred">1.1</font>"/>
<font color="gray"><i><!-- the set of attributes associated with the
dependecy --></i></font>
<attributes>
<font color="gray"><i><!--
Service type constraints go here.
--></i></font>
</attributes>
</dependency>
</dependencies>
</component-info>
</pre>
<p>
Given a set of compoenent types Merlin initially establishes the set of
candidates based on the declared dependecies and services. For every component
declared or implied in the assembly Merlin will attempt to locate a set of
candidate supplies. For every supplier Merlin will attempt to resolve the
suppliers dependecies. If a failure occurs, the failed component is disgarded
as a potential supplier candidate. Each component type is associated with at
least one instantiation profile (explicit, packaged, and/or explicit).
Profiles imply an inital ranking of candidates. Explicit profiles (that is
component declarations included within a container declaration in the kernel
defintion) are given highest priority. Package profiles (profiles declared in
a <class-name>.xprofile resource take second priority, following by
implicit profiles (only generated in the absence of explicit or packaged
profiles).
</p>
<p>Profiles appear as declarations inside container defintions. A typical
profile declaration includes inforation about the configuration, context and
logging setup of the component type. An example component profile is included
below:</p>
<pre>
<font color="gray"><i><!--
Declaration of the services hosted by this container. Service container
here
will be managed relative to other provider components at the same level
and
may be serviced by components declared in parent container.
--></i></font>
<component name="<font color="darkred">complex</font>" class="<font
color="darkred">org.apache.excalibur.playground.ComplexComponent</font>"
activation="<font color="darkred">startup</font>">
<loggers priority="<font color="darkred">DEBUG</font>">
<category name="<font color="darkred">init</font>"
priority="<font color="darkred">DEBUG</font>" />
</loggers>
<font color="gray"><i><!--
Include the following context value in the context supplied a
component using this
profile. Context entries are normally only required in the case
where the component
type declares a required context type and entry values. Generally
speaking, a component
will normally qualify it's instantiation criteria through a
configuration declaration.
Any context values defined at this level will override context values
supplied by the
container.
--></i></font>
<context>
<entry name="<font color="darkred">location</font>" value="<font
color="darkred">Paris</font>"/>
</context>
<font color="gray"><i><!--
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
supplied here.
--></i></font>
<configuration>
<message value="<font color="darkred">Hello</font>"/>
</configuration>
<font color="gray"><i><!--
The parameterization criteria from this instance of the component
type.
--></i></font>
<parameters/>
</component>
</pre>
<p>In the majority of cases, a single candidate will be located to act as a
supplier. In those occasions where multiple candidates exist, Merlin will
invoke a candidate selection process. This pocesses involves instantiation of
a service selector from one of the following sources:</p>
<p>
<ul>
<li>a classname declared as a value of the depedency 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>
</ul>
</p>
<p>
The service <a
href="api/assembly/org/apache/excalibur/merlin/container/Selector.html">Selector</a>
will be supplied with the set of candidate profiles and the set of known
facilities. In this context a facility is a component that has already been
assembled (either expliciity or implicity as a result of another denpdency).
The default selector will attempt to resolve the selection by applying the
following tests:
</p>
<p>
<ul>
<li>an explicit profile</li>
<li>a facility (kernel wide selection scope)</li>
<li>a packaged profile</li>
<li>an implicit profile</li>
</ul>
</p>
<p><i>Please note that the selection model and interfaces may be changed as a
result of more intensive usage assessment. The current approach of supplying a
non-ordered set of profiles negates the possibility for order upward searching
within a container hierachy. An alternative approach of delegating the selction
to the container based on a supplier selection handler is under consideration.
</i></p>
<p>On completion of a selection process a graph of candidates is established
from which the order establishment of services is resolved and Merlin proceeds
with the service <a href="activation.html">activation</a> phase.</p>
</section>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
$Revision: 1.1 $ $Date: 2002/07/21 05:04:10 $
</legal>
</footer>
</document>
1.1 jakarta-avalon-excalibur/assembly/src/xdocs/classpath.xml
Index: classpath.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Classpath</title>
<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>
<pre>
<kernel>
</pre>
<p><font color="gray"><i><!--
Declaration of a kernel level classpath.
--></i></font></p>
<pre>
<classpath">
<fileset dir="<font color="darkred">lib</font>">
<include name="<font
color="darkred">avalon-framework.jar</font>"/>
<include name="<font color="darkred">logkit.jar</font>"/>
</fileset>
</classpath">
</pre>
<p><font color="gray"><i><!--
Other kernel declarations.
--></i></font></p>
<pre>
<container name="<font color="darkred">root</font>">
</pre>
<p><font color="gray"><i><!--
Declaration of a container level classpath.
--></i></font></p>
<pre>
<classpath">
<fileset dir="<font color="darkred">dist</font>">
<include name="<font color="darkred">demo.jar</font>"/>
</fileset>
</classpath">
</pre>
<p><font color="gray"><i><!--
Component profiles and/or subsidiary containers will normally appear here.
--></i></font></p>
<pre>
</container>
</kernel>
</pre>
</section>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
$Revision: 1.1 $ $Date: 2002/07/21 05:04:10 $
</legal>
</footer>
</document>
1.1 jakarta-avalon-excalibur/assembly/src/xdocs/export.xml
Index: export.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Export</title>
<author email="[EMAIL PROTECTED]">Stephen McConnell</author>
</properties>
<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.
</p>
</section>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
$Revision: 1.1 $ $Date: 2002/07/21 05:04:10 $
</legal>
</footer>
</document>
1.1
jakarta-avalon-excalibur/assembly/src/xdocs/extensions.xml
Index: extensions.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>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>
<pre>
<kernel>
</pre>
<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>
<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>
</section>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
$Revision: 1.1 $ $Date: 2002/07/21 05:04:10 $
</legal>
</footer>
</document>
1.1 jakarta-avalon-excalibur/assembly/src/xdocs/faq.xml
Index: faq.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>FAQ</title>
<author email="[EMAIL PROTECTED]">Stephen McConnell</author>
</properties>
<body>
<section name="Frequently Asked Questions">
<p>In preparation.</p>
</section>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
$Revision: 1.1 $ $Date: 2002/07/21 05:04:10 $
</legal>
</footer>
</document>
1.1 jakarta-avalon-excalibur/assembly/src/xdocs/install.xml
Index: install.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Installation</title>
<author email="[EMAIL PROTECTED]">Stephen McConnell</author>
</properties>
<body>
<section name="Installation">
<subsection name="Dependecies">
<p>
Installation of Merlin assumes you have Ant 1.4 or later installled on you
machine.
</p>
<p><a href="http://jakarta.apache.org/ant/index.html";>Ant Home Page</a></p>
</subsection>
<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):
</p>
<pre>
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login
password: anoncvs
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout
jakarta-avalon-excalibur/assembly
</pre>
</subsection>
<subsection name="Build Procedure">
<p>
To build the Merlin installation, cd to the location of the Merlin project
(e.g. C:\jakarta-avalon-excalibur\merlin ) and invoke ant.
</p>
<pre>
$ ant
</pre>
</subsection>
</section>
<section name="Demo">
<p>
To run a demonstration of Merlin run the kernel command file.
</p>
<pre>
$ kernel
</pre>
</section>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
$Revision: 1.1 $ $Date: 2002/07/21 05:04:10 $
</legal>
</footer>
</document>
1.1 jakarta-avalon-excalibur/assembly/src/xdocs/list.xml
Index: list.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Email</title>
<author email="[EMAIL PROTECTED]">Stephen McConnell</author>
</properties>
<body>
<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.
</p>
</section>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
$Revision: 1.1 $ $Date: 2002/07/21 05:04:10 $
</legal>
</footer>
</document>
1.1 jakarta-avalon-excalibur/assembly/src/xdocs/logging.xml
Index: logging.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Logging</title>
<author email="[EMAIL PROTECTED]">Stephen McConnell</author>
</properties>
<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>
</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>
<pre>
<kernel>
</pre>
<font color="gray"><i><!--
Definition of a logging system. The priority and target attributes
declare system wide defaults
--></i></font>
<pre>
<logging priority="<font color="darkred">INFO</font>" target="<font
color="darkred">kernel</font>">
</pre>
<font color="gray"><i><!--
Multiple targets may be included - each defining a logging file.
--></i></font>
<pre>
<target name="<font color="darkred">kernel</font>">
<file location="<font color="darkred">kernel.log</font>" />
</target>
</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. In this context the container is the kernel. As such a
category name
of "logging" translates to a full loggin category path of
"kernel.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></p>
<pre>
<loggers priority="<font color="darkred">INFO</font>">
<category name="<font color="darkred">logging</font>"
priority="<font color="darkred">WARN</font>"/>
<category name="<font color="darkred">installer</font>"
priority="<font color="darkred">WARN</font>"/>
<category name="<font color="darkred">installer.type</font>"
priority="<font color="darkred">WARN</font>"/>
<category name="<font
color="darkred">installer.type.builder</font>" priority="<font
color="darkred">WARN</font>"/>
<category name="<font color="darkred">loader</font>"
priority="<font color="darkred">WARN</font>"/>
<category name="<font color="darkred">loader.type</font>"
priority="<font color="darkred">WARN</font>"/>
<category name="<font color="darkred">loader.type.builder</font>"
priority="<font color="darkred">WARN</font>"/>
<category name="<font color="darkred">export</font>"
priority="<font color="darkred">WARN</font>"/>
</loggers>
</pre>
<p><font color="gray"><i><!--
Other kernel declarations.
--></i></font></p>
<pre>
</kernel>
</pre>
<p>Logging sub-categories within the kernel category include:
<ul>
<li><b>logging</b>, information concerning the creation of new logging
categories and targets</li>
<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>
</ul>
</p>
<p>All logging categories declarted at kernel level are scoped relative
to the "kernel" root category. At such, a parameter dealing with a category
such "loader" is equivilent to the full category path "kernel.loader".</p>
</section>
<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>Logging sub-categories within the container category include:
<ul>
<li><b>loader</b>, the classloader that handles container
establishment</li>
<li><b>loader.types</b>, type registration</li>
<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 lifecycle handler sub-system</li>
</ul>
</p>
<p>An example container logging declaration is shown below.</p>
<pre>
<kernel>
<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>
</p>
<pre>
<loggers priority="<font color="darkred">INFO</font>">
<category name="<font color="darkred">loader</font>"
priority="<font color="darkred">WARN</font>"/>
<category name="<font color="darkred">loader.type</font>"
priority="<font color="darkred">WARN</font>"/>
<category name="<font color="darkred">loader.type.builder</font>"
priority="<font color="darkred">WARN</font>"/>
<category name="<font color="darkred">assembly</font>"
priority="<font color="darkred">WARN</font>"/>
<category name="<font color="darkred">assembly.selector</font>"
priority="<font color="darkred">WARN</font>"/>
<category name="<font color="darkred">provider</font>"
priority="<font color="darkred">WARN</font>"/>
<category name="<font color="darkred">lifecycle</font>"
priority="<font color="darkred">WARN</font>"/>
</loggers>
</pre>
<p><font color="gray"><i><!--
Other container declarations.
--></i></font></p>
<pre>
</container>
</kernel>
</pre>
</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>
<pre>
<kernel>
<p><font color="gray"><i><!-- A classpath declaration could be included
here or under the container scope. --></i></font></p>
<container name="<font color="darkred">root</font>">
</pre>
<font color="gray"><i><!--
Component profile declaration.
--></i></font>
<pre>
<component name="<font color="darkred">complex</font>" class="<font
color="darkred">org.apache.excalibur.playground.ComplexComponent</font>"
activation="<font color="darkred">true</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 component. As such a category name of "init" translates to a
full logging category path of <container-path>root.init. The logging
element may contain priority and target attribute values. These values will
overide the container wide defaults. --></i></font>
</p>
<pre>
<loggers priority="<font color="darkred">DEBUG</font>">
<category name="<font color="darkred">init</font>"
priority="<font color="darkred">WARN</font>"/>
</loggers>
</component>
</pre>
<p><font color="gray"><i><!-- Other container declarations.
--></i></font></p>
<pre>
</container>
</kernel>
</pre>
</section>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
$Revision: 1.1 $ $Date: 2002/07/21 05:04:10 $
</legal>
</footer>
</document>
1.1 jakarta-avalon-excalibur/assembly/src/xdocs/support.xml
Index: support.xml
===================================================================
<?xml version="1.0"?>
<document>
<properties>
<title>Support</title>
<author email="[EMAIL PROTECTED]">Stephen McConnell</author>
</properties>
<body>
<section name="Commercial Support">
<p>
Product support for Merlin is available on contract terms through <a
href="http://home.osm.net";>OSM SARL</a>.
</p>
</section>
<section name="OSM Service Development">
<p>
Business components under development by OSM that leverage the Merlin service
management platform include the following:
</p>
<table width="100%" cellpadding="3" cellspacing="3" border="0">
<tr valign="top" bgcolor="lightsteelblue">
<td class="mini" width="40">Version</td>
<td class="mini" width="100">Package</td>
<td class="mini">Description</td>
</tr>
<tr valign="top" bgcolor="lightgrey">
<td class="mini">0.7</td>
<td class="mini"><a href="../discovery/index.html">Registration
and Discovery</a></td>
<td class="mini">Services supporting the registration and
discovery of information and service resources, maintenance of information
(updating, replacement, retraction), and the referral of information and
service descriptions.</td></tr>
<tr valign="top" bgcolor="lightgrey">
<td class="mini">0.7</td>
<td class="mini"><a
href="../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>
<tr valign="top" bgcolor="lightgrey">
<td class="mini">0.8</td>
<td class="mini"><a href="../community/index.html">Community
Framework</a></td>
<td class="mini">Component providing support for the management
of shared workspaces and membership semantics based on business roles,
associated community and membership policies, notions of implicit roles,
management of quorums, and control over membership to user
associations.</td></tr>
<tr valign="top" bgcolor="lightgrey">
<td class="mini">2.1</td>
<td class="mini"><a href="../session/index.html">Session
Framework</a></td>
<td class="mini">Service components supporting the
establishment and management of people, places, things and business processes.
The framework supplies a common business model through which business services
may be activated as process, associated to users as tasks, consuming and
producing resources that may be published in provate and shared workspaces,
across a distribution information system.</td></tr>
<tr valign="top" bgcolor="lightgrey">
<td class="mini">0.9</td>
<td class="mini"><a
href="../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>
</table>
<p><img src="/images/nothing.gif" border="0"/></p>
</section>
</body>
<footer>
<legal>
Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
$Revision: 1.1 $ $Date: 2002/07/21 05:04:10 $
</legal>
</footer>
</document>
1.1
jakarta-avalon-excalibur/assembly/src/xdocs/images/nothing.gif
<<Binary file>>
1.2 +20 -1
jakarta-avalon-excalibur/assembly/src/xdocs/stylesheets/project.xml
Index: project.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon-excalibur/assembly/src/xdocs/stylesheets/project.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- project.xml 17 Jul 2002 13:48:38 -0000 1.1
+++ project.xml 21 Jul 2002 05:04:11 -0000 1.2
@@ -16,11 +16,30 @@
<item name="Deployment" href="/deployment.html"/>
</menu>
+ <menu name="Getting Started">
+ <item name="Installation" href="/install.html"/>
+ <item name="FAQ" href="/faq.html"/>
+ </menu>
+
+ <menu name="Facilities">
+ <item name="Logging" href="/logging.html"/>
+ <item name="Extensions" href="/extensions.html"/>
+ <item name="Classpath" href="/classpath.html"/>
+ <item name="Assembly" href="/assembly.html"/>
+ <item name="Activation" href="/activation.html"/>
+ <item name="Export" href="/export.html"/>
+ </menu>
+
+ <menu name="Support">
+ <item name="Mailing List" href="/list.html"/>
+ <item name="Commercial Links" href="/support.html"/>
+ </menu>
+
<menu name="Reference">
<item name="Merlin API" href="/api/assembly/index.html"/>
<item name="Meta-Info API" href="/api/meta/index.html"/>
</menu>
</body>
-
+
</project>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
