You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by ni...@apache.org on 2004/03/13 14:16:21 UTC
cvs commit: avalon-site/xdocs/product/containers history.xml index.xml
niclas 2004/03/13 05:16:21
Modified: xdocs/product index.xml
xdocs/product/containers index.xml
Added: xdocs/product/containers history.xml
Log:
Some explaination of container works, and relegated the old page to history.
Revision Changes Path
1.2 +36 -28 avalon-site/xdocs/product/index.xml
Index: index.xml
===================================================================
RCS file: /home/cvs/avalon-site/xdocs/product/index.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.xml 2 Nov 2003 11:10:49 -0000 1.1
+++ index.xml 13 Mar 2004 13:16:21 -0000 1.2
@@ -12,34 +12,42 @@
</p>
<table>
<tr>
- <th>Name</th>
- <th>Description</th>
- </tr>
- <tr>
- <td><a href="framework/index.html">Framework</a></td>
- <td>
- <p>The framework collection includes a component meta model
- used to describe component dependencies towards a container, and,
- the classic framework APIs that describe the runtime contact
- between a container and a component.</p>
- </td>
- </tr>
- <tr>
- <td><a href="containers/index.html">Containers</a></td>
- <td>
- <p>A container is a platform supporting the management of
- components. This page provides an overview of current and
- legacy container solutions and links to respective home pages.</p>
- </td>
- </tr>
- <tr>
- <td><a href="components/index.html">Components</a></td>
- <td>
- <p>The components page provides a summary of the two main
- component groups in Avalon - the course grained cornerstone
- suite and the fine grain utilites under Excalibur.</p>
- </td>
- </tr>
+ <th>Name</th>
+ <th>Description</th>
+ </tr>
+ <tr>
+ <td><a href="framework/index.html">Framework</a></td>
+ <td>
+ <p>The framework collection includes a component meta model
+ used to describe component dependencies towards a container, and,
+ the classic framework APIs that describe the runtime contact
+ between a container and a component.</p>
+ </td>
+ </tr>
+ <tr>
+ <td><a href="containers/index.html">Containers</a></td>
+ <td>
+ <p>
+ A container is a platform supporting the management of
+ components. This page tries to explain how component
+ management is done in Avalon.
+ </p>
+ <p>
+ In March 2004, Avalon community decided to focus on a single
+ reference container, which is
+ <a href="../merlin/index.html">Merlin</a>, but this page
+ also give some history on how we arrived where we are.
+ </p>
+ </td>
+ </tr>
+ <tr>
+ <td><a href="components/index.html">Components</a></td>
+ <td>
+ <p>The components page provides a summary of the two main
+ component groups in Avalon - the course grained cornerstone
+ suite and the fine grain utilites under Excalibur.</p>
+ </td>
+ </tr>
</table>
</section>
</body>
1.4 +226 -93 avalon-site/xdocs/product/containers/index.xml
Index: index.xml
===================================================================
RCS file: /home/cvs/avalon-site/xdocs/product/containers/index.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- index.xml 23 Dec 2003 02:09:02 -0000 1.3
+++ index.xml 13 Mar 2004 13:16:21 -0000 1.4
@@ -6,100 +6,233 @@
</properties>
<body>
- <section name="Products">
- <subsection name="Container Solutions">
-
- <p>Within Avalon their are a number of container solutions. This
- reflects a historical divergence and a present convergence within
- the area of containment technology within Avalon. The original
- containment solutions ECM and Phoenix focussed on very different
- approaches to component management. The ECM model dealt with
- primarily pooled objects used in environments such as
- <a href="http://cocoon.apache.org/">Cocoon</a>. The
- Phoenix model dealt with a strict singleton model supporting
- project such as <a href="http://james.apache.org">James</a>.
- Recent developments have resulted in the
- release of
- <a href="http://avalon.apache.org/excalibur/fortress/">Fortress</a>
- and <a href="http://avalon.apache.org/merlin/">Merlin</a>.
- Fortress replaces the ECM solution
- and is positioned as a migration vehicle for components to move
- towards Avalon's latest container - Merlin. The Merlin container
- is an attempt at being a flexible and adaptive embedded container
- that leverages a set of common containment facilities.
- Merlin provides support for legacy Phoenix components and includes
- many of of the lifestyle concepts introduced within Fortress.</p>
+ <section name="History" >
+ <p>
+ For those who are interested in the past, and how we arrived with
+ Merlin, can take a look at <a href="history.html">this page</a>.
+ </p>
+ </section>
+
+ <section name="Avalon Container Management">
+ <subsection name="Purpose" >
+ <p>
+ The purpose of the container is to manage the components under its
+ care. That typically involves various creation and destruction
+ stages, or what we call the LifeCycle. Part of the creation stages
+ is the different needs the component has, such as it may need a
+ Logger, so the container has to provide it, it may need some type
+ of configuration and the container has to provide, and so on.
+ </p>
+ <p>
+ The container is also responsible to fulfill other concerns of the
+ management contract, such as LifeStyle, Security, Dependencies,
+ JAR handling and so on. Basically, the container should take care
+ of everything required to get the component operational.
+ </p>
+ </subsection>
+
+ <subsection name="Container-Component Contract" >
+ <p>
+ Avalon Framework and associated material specifies, among other
+ things a contract between the component and the container. That
+ means that if the component fulfills its obligations, the container
+ will provide the component with its needs. Example; If the component
+ declares that it implements LogEnabled, the container will provide
+ the component with an initialized and ready-to-use Logger instance.
+ </p>
+
+ </section>
+ </section>
+
+ <section name="Container Provisions" >
+ <subsection name="Logging" >
+ <p>
+ If the component declares that it implements the LogEnabled inteface,
+ a ready-to-use, Logger instance will be provided through the method;
+ </p>
+<source>
+ public void enableLogging( Logger logger )
+ {
+ }
+</source>
+ <p>
+ The Merlin container supports both LogKit and Log4J logging subsystem,
+ and please look at the
+ <a href="../../logging/index.html">Avalon Logging</a> subsystem for
+ details.
+ </p>
+ </subsection>
+
+ <subsection name="Dependencies" >
+ <p>
+ There are many ways on how to resolve dependencies between components.
+ Avalon uses a method called <emp>Lookup Injection</emp>, which means
+ that the container will hand over a ServiceManager to the component,
+ if the component implements the Serviceable interface.
+ </p>
+<source>
+ public void service( ServiceManager manager )
+ {
+ }
+</source>
+ <p>
+ The ServiceManager will only provide the component with components
+ that satisfy the <strong>dependencies</strong> declaration in the
+ component's
+ <a href="../../meta/meta/info/type/index.html">Type descriptor</a>
+ (.xinfo). If it attempts to lookup anything outside the declared
+ dependencies, the container is expected to throw a ServiceException.
+ </p>
+ <p>
+ And Merlin is so clever that the component will never be deployed
+ if the dependencies could not be satisfied, so if the component
+ follows its obligations, i.e. only looking up declared dependencies,
+ the container will supply the solution, always!
+ </p>
+ </subsection>
+
+ <subsection name="Configuration" >
+ <p>
+ Many components are generic and can be tweaked into doing slightly
+ different things, according to some settings. We call those settings
+ Configuration, and is supply to the component if the component
+ implements the Configurable interface.
+ </p>
+<source>
+ public void configure( Configuration conf )
+ {
+ }
+</source>
+ <p>
+ The above construct allow for very complex Configurations, using
+ XML nested elements, but not any XML, it must follow certain rules.
+ See <a href="../../framework/api/org/apache/avalon/framework/configuration/Configuration.html">
+ Configuration</a> API docs for details.
+ </p>
+ </subsection>
+
+ <subsection name="Contextualization" >
+ <p>
+ Contextualization is about establishing a containment context. That
+ means that there must be certain container features available to the
+ component for it to function properly. This is slightly different
+ from normal service dependencies, as context entries can be of any
+ type, such as java.io.File for the standard "urn:avalon:home"
+ context entry.
+ </p>
+<source>
+ public void contextualize( Context context )
+ {
+ }
+</source>
+ <p>
+ It is also possible to create custom context entries.
+ <a href="../../merlin/starting/advanced/context.html">Read more about it.</a>
+ </p>
+ </subsection>
+
+ <subsection name="Repository" >
+ <p>
+ We have all been in <emp>JAR Hell</emp>, which means that it is hard
+ to keep track of which Jars are required, and more importantly which
+ version of each. And that is only for your build system. When you
+ start deploying the applications, this grows into a nightmare.
+ This has been highlighted for quite some time within
+ The Apache Software Foundation, and Maven has addressed it for build
+ systems, and recently (March 2004) a new more generic project called
+ Depot started in the incubator, which will address this problem.
+ </p>
+ <p>
+ Avalon has in the meantime created the
+ <a href="../../repository/index.html">Avalon Repository</a> which allows
+ the applications to be distributed without any Jars, and the right
+ versions of the Jars will be picked up at one or many central
+ repositories. This system is compatible with the Maven repositories,
+ so we have instantly access to hundreds of projects at repositories,
+ such as ibiblio.org.
+ </p>
+ </subsection>
+ </section>
+
+ <section name="Container Deployment Cases" >
+ <subsection name="Stand-alone Server" >
+ <p>
+ The most straight forward deployment case is the stand-alone server,
+ that is started from the command-line. No programming is required,
+ and there are heaps of command-line arguments available. Read about
+ the details <a href="../../merlin/merlin/kernel/cli.html">here</a>.
+ </p>
+ <p>
+ Merlin even supports that it is bootstrapped, with a tiny JAR, which
+ will pick up and start Merlin (or any other compliant artifact) from a
+ central repository. One can on the command-line specify which version
+ of Merlin one wishes to start, and provide the application block
+ reference, effectively selecting which application to start.
+ </p>
+ <p>
+ If a central repository is not desirable, Merlin's binary distribution
+ contains all that is required to run, except the application block
+ itself, which may either be local or online.
+ </p>
+ </subsection>
+
+ <subsection name="Stand-alone GUI Application" >
+ <p>
+ There is actually no difference between a stand-alone server and a
+ stand-alone GUI application. In fact, with good Component Oriented
+ practices, one can completely separate the business logic in the
+ application, and provide a GUI interface or a Web interface simply
+ by changing the block definition file.
+ </p>
+ </subsection>
+
+ <subsection name="Running as a Windows NT/XP Service" >
+ <p>
+ Merlin is capable of starting as a Windows NT/XP Service. You can
+ read about how on <a href="../../merlin/merlin/kernel/nt.html">this
+ page.</a>
+ </p>
+ </subsection>
+
+ <subsection name="Embedded in generic Application" >
+ <p>
+ If you have an existing application that you want to complement with
+ Avalon component management, without refactoring the whole application
+ into components, you will need to create Merlin embedded inside your
+ application. About 10-15 lines of code is currently required, where
+ the InitialContext is established, the Directives are setup and a
+ Kernel is created. It looks more complicated than it is, but it is
+ extremely powerful, and allows the same features as the stand-alone
+ server, in fact the small bootstrapper in the stand-alone case, does
+ exactly the same thing.
+ </p>
+ </subsection>
- <table>
- <tr><th>Product</th><th>Description</th></tr>
- <tr>
- <td>
- <p>
- <a name="merlin"/>
- <a href="http://avalon.apache.org/merlin/index.html">Avalon Merlin</a>
- </p>
- </td>
- <td>
- <p>
- The Merlin project deals with the broad area of service
- and component management. The Merlin system is a container
- that provides comprehensive support for the management of
- complex component-based systems. Merlin uses a component
- meta-model to facilitate the automated assembly and
- deployment of simple and composite components.
- </p>
- </td>
- </tr>
- <tr>
- <td>
- <p>
- <a name="fortress"/>
- <a href="http://avalon.apache.org/excalibur/fortress/">Avalon Fortress</a>
- </p>
- </td>
- <td>
- <p>
- Fortress contains a framework to help you create your own
- avalon containers. It boasts asynchronous management of your
- component instances, high scalability, easier maintenance of
- your code, and easy embedding into various environments like
- servlet engines.
- </p>
- </td>
- </tr>
- <tr>
- <td>
- <p>
- <a name="ecm"/>
- <a href="http://avalon.apache.org/excalibur/component.html">ECM</a>
- </p>
- </td>
- <td>
- <p>
- This package contains the ExcaliburComponentManager (ECM). ECM has
- been depricated in favour of the new Fortress container.</p>
- </td>
- </tr>
- <tr>
- <td>
- <p>
- <a name="phoenix"/>
- <a href="http://avalon.apache.org/phoenix/index.html">Phoenix</a>
- </p>
- </td>
- <td>
- <p>
- Phoenix is a micro-kernel designed and implemented on top of
- the Avalon framework. It provides a number of facilities to
- manage the environment of Server Applications. Such facilities
- include log management, classloading, thread management and
- security.
- </p>
- </td>
- </tr>
- </table>
+ <subsection name="Embedded in a Servlet" >
+ <p>
+ If the Servlet engine allows, it is possible to embedd Merlin inside
+ a Servlet. The code required to do it, can be seen
+ <a href="../../merlin/extensions/servlet/index.html">here</a>.
+ It is expected that this Servlet will undergo some enhancement prior
+ to be officially released in the Merlin distribution. This is to
+ ensure maximum usability for our users.
+ </p>
+ </subsection>
+
+ <subsection name="Embedded in Application Server" >
+ <p>
+ Embedding in Application Servers can prove to be a lot more
+ complicated than in generic Application, since the App Servers very
+ often imposes restrictions on the parts that it hosts, such as
+ security restrictions, classloading restrictions and similar. It is
+ basically a case of trying to get a operating system running inside
+ another operating system, both competing for the same resources.
+ </p>
+ <p>
+ One of the objectives of the Avalon community is to work out what is
+ possible, and how, and what can not be done, in this area.
+ </p>
</subsection>
</section>
</body>
-</document>
-
\ No newline at end of file
+</document>
\ No newline at end of file
1.1 avalon-site/xdocs/product/containers/history.xml
Index: history.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<document>
<properties>
<author email="dev@avalon.apache.org">Avalon Documentation Team</author>
<title>Apache Avalon: Containers</title>
</properties>
<body>
<section name="History of Container Solutions">
<p>
Within Avalon there has been a number of container solutions. This
reflects a historical divergence and a present convergence within
the area of containment technology within Avalon. The original
containment solutions ECM and Phoenix focussed on very different
approaches to component management. The ECM model dealt with
primarily pooled objects used in environments such as
<a href="http://cocoon.apache.org/">Cocoon</a>. The
Phoenix model dealt with a strict singleton model supporting
project such as <a href="http://james.apache.org">James</a>.
Further developments resulted in the release of
<a href="http://avalon.apache.org/excalibur/fortress/">Fortress</a>
and <a href="http://avalon.apache.org/merlin/">Merlin</a>.
Fortress replaced the ECM solution
and was positioned as a migration vehicle for components to move
towards Avalon's latest container - Merlin. The Merlin container
is an attempt at being a flexible and adaptive container
that leverages a set of common containment facilities, equally
suited for embedded and stand-alone use.
</p>
<p>
The Avalon community went into an identity crisis, and was struggling
to support multiple containers. This also lead to decision paralysis
and community division. In March 2004, the community finally pulled
itself together and made the historic vote to forge forward with a
<strong>Single Platform</strong>, and only Merlin fits the bill of
being that platform.
</p>
<p>
Below is the previous explainations of each of the containers.
However, Avalon recommend that new users only invest time in
Merlin, the only sustainable solution. ECM and Fortress will be
partially supported during a transition period, but eventually
taken out of Avalon completely. Users who are interested in Phoenix
and that can't use Merlin, can investigate if the
<a href="http://loom.jcontainer.org">Loom project</a> can be of any
assistance.
</p>
<table>
<tr><th>Product</th><th>Description</th></tr>
<tr>
<td>
<p>
<a name="merlin"/>
<a href="http://avalon.apache.org/merlin/index.html">Avalon
Merlin</a>
</p>
</td>
<td>
<p>
The Merlin project deals with the broad area of service
and component management. The Merlin system is a container
that provides comprehensive support for the management of
complex component-based systems. Merlin uses a component
meta-model to facilitate the automated assembly and
deployment of simple and composite components.
</p>
</td>
</tr>
<tr>
<td>
<p>
<a name="fortress"/>
<a href="http://avalon.apache.org/excalibur/fortress/">Avalon
Fortress</a>
</p>
</td>
<td>
<p>
Fortress contains a framework to help you create your own avalon
containers. It boasts asynchronous management of your component
instances, high scalability, easier maintenance of your code, and
easy embedding into various environments like servlet engines.
</p>
</td>
</tr>
<tr>
<td>
<p>
<a name="ecm"/>
<a href="http://avalon.apache.org/excalibur/component.html">ECM</a>
</p>
</td>
<td>
<p>
This package contains the ExcaliburComponentManager (ECM). ECM has
been deprecated in favour of the new Fortress container.
</p>
</td>
</tr>
<tr>
<td>
<p>
<a name="phoenix"/>
<a href="http://avalon.apache.org/phoenix/index.html">Phoenix</a>
</p>
</td>
<td>
<p>
Phoenix is a micro-kernel designed and implemented on top of
the Avalon framework. It provides a number of facilities to
manage the environment of Server Applications. Such facilities
include log management, classloading, thread management and
security.
</p>
</td>
</tr>
</table>
</section>
</body>
</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
For additional commands, e-mail: cvs-help@avalon.apache.org