blob: c4311c2e9dab7bc11215b4f0cff7b62484ba2999 [file] [log] [blame]
<?xml version="1.0"?>
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<document>
<properties>
<title>Fulcrum YAAFI Avalon Container</title>
<author email="siegfried.goeschl@it20one.at">Siegfried Goeschl</author>
</properties>
<body>
<section name="What is YAAFI?">
<p>
The Yet Another Avalon Framework Implementation of an Avalon container.
</p>
<p>
YAAFI is a light-weight implementation of a service framework using the
Avalon service lifecycle interfaces aka Avalon container. There are a
few other implementations out there such as Phoenix, Fortress, Loom,
Keel and Merlin but YAAFI gives you a lot of bells and whistles with minimal baggage.
The goal of the implementation is to provide a light-weight Avalon container
to be embedded into existing applications and/or other containers.
</p>
<subsection name="What we left out">
<p>
<ul>
<li>logger manager implementation since this is done by log4j quite nicely</li>
<li>run-time instrumentation to monitor application health</li>
<li>service implementation versioning</li>
<li>service initialization in a background thread</li>
<li>no support for lifestyle other than Singleton</li>
<li>classloader hierarchies for components</li>
<li>service selector implementation</li>
<li>no javadoc tag support for automatically creating component decriptors</li>
</ul>
</p>
</subsection>
<subsection name="What we actually implemented">
<p>
<ul>
<li>a light-weight Avalon container only depending an the Avalon Framework libraries</li>
<li>a container which can run components written for ECM, Fortress, Phoenix and Merlin</li>
<li>ability to be embedded in other Avalon containers such as Phoenix</li>
<li>automatic reconfiguration for the whole Avalon container or individual services</li>
<li>automatic shutdown of the whole Avalon container</li>
<li>support for early or on-demand initialization</li>
<li>support for encrypted configuration files</li>
<li>dynamic proxies and service interceptors</li>
<li>dynamic expansion of variables found in the component configuration file</li>
</ul>
</p>
</subsection>
<subsection name="The rest of the Avalon universe">
<p>
<ul>
<li>
<a href="http://excalibur.apache.org/fortress/">Fortress</a> is another Avalon container under the
Apache umbrella. It is also targeted to be embedded into existing
applications.
</li>
<li>
<a href="http://loom.codehaus.org/">Loom</a> is another Avalon based micro-kernel
derived from Phoenix
</li>
<li>
<a href="http://dpml.net/metro/latest/">Metro</a> was meant as unification
of Avalon containers but moved away from Apache.
</li>
<li>
<a href="http://plexus.codehaus.org/">Plexus</a> another light-weight being
able to run Avalon components.
</li>
<li>
<a href="http://xingu.sourceforge.net/">Xingu</a> is a Avalon-based
component repository.
</li>
</ul>
</p>
</subsection>
</section>
</body>
</document>