leosimons 2003/02/03 07:36:01
Modified: proposal/framework-forrest/src/documentation/content/xdocs
book.xml designing-a-component.xml
getting-started.xml guide-cop-in-avalon.xml
guide-cop-what-is.xml guide-oop-best-practices.xml
guide-patterns-in-avalon.xml
guide-patterns-ioc-security.xml
guide-patterns-ioc.xml guide-patterns-soc.xml
guide-patterns-soii.xml guide-patterns-what-are.xml
guide-where-to-go-from-here.xml index.xml
reference-containers.xml
reference-the-lifecycle.xml
Log:
Applying patch from bug 16660
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16660), fixing lots of typos.
Submitted by [EMAIL PROTECTED] (Ulrich Mayring). Thanks Ulrich!
Revision Changes Path
1.2 +5 -5
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/book.xml
Index: book.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/book.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- book.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ book.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -8,17 +8,17 @@
<menu label="Essentials">
<menu-item label="Overview" href="index.html"/>
- <menu-item label="Getting started" href="getting-started.html"/>
+ <menu-item label="Getting Started" href="getting-started.html"/>
<menu-item label="Download"
href="http://jakarta.apache.org/builds/jakarta-avalon/release/framework"/>
</menu>
<menu label="Guide">
- <menu-item label="OOP best practices" href="guide-oop-best-practices.html"/>
- <menu-item label="What are patterns?" href="guide-patterns-what-are.html"/>
+ <menu-item label="OOP best Practices" href="guide-oop-best-practices.html"/>
+ <menu-item label="What are Patterns?" href="guide-patterns-what-are.html"/>
<menu-item label="Patterns in Avalon" href="guide-patterns-in-avalon.html"/>
<menu-item label="What is COP?" href="guide-cop-what-is.html"/>
<menu-item label="COP in Avalon" href="guide-cop-in-avalon.html"/>
- <menu-item label="Where to go from here"
href="guide-where-to-go-from-here.html"/>
+ <menu-item label="Where to Go from here"
href="guide-where-to-go-from-here.html"/>
</menu>
<menu label="Reference">
@@ -26,4 +26,4 @@
<menu-item label="The Lifecycle" href="reference-the-lifecycle.html"/>
<menu-item label="Containers" href="reference-containers.html"/>
</menu>
-</book>
\ No newline at end of file
+</book>
1.2 +11 -11
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/designing-a-component.xml
Index: designing-a-component.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/designing-a-component.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- designing-a-component.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ designing-a-component.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -13,17 +13,17 @@
<section>
<title>How is the Component Going to be Used?</title>
<p>
- The first step in writing the Component is determining how it is going
+ The first step in writing the component is determining how it is going
to be used. There will be a number of times where you have a powerful
- Component that can be used in many different contexts. Those contexts
- may include executing the Component from the command line (separate
+ component that can be used in many different contexts. Those contexts
+ may include executing the component from the command line (separate
from Avalon), using it as a part of a sub system, or using it as an
integral part of Avalon.
</p>
<section>
<title>Part of Avalon</title>
<p>
- All Components are an integral part of Avalon, so there is really
+ All components are an integral part of Avalon, so there is really
nothing to be done beyond specifying its interface (role). It is
important to identify and document its social contract with the
rest of the system. What I mean by social contract is the order
@@ -35,7 +35,7 @@
<title>Part of a Sub System</title>
<p>
A sub system can either be part of Avalon, or live in a separate
- context. A perfect example would be a Component that can function
+ context. A perfect example would be a component that can function
within a Servlet or Enterprise Application. Neither of those
contexts are native to Avalon (though they can easily be built
on top of Avalon).
@@ -47,7 +47,7 @@
</p>
<p>
Because the contexts may not be an integral part of Avalon,
- you must take care to use the Component in the same manner as
+ you must take care to use the component in the same manner as
Avalon would. That means that you follow the order of concerns
that Avalon has specified for those concerns.
</p>
@@ -55,24 +55,24 @@
<section>
<title>A Stand Alone Program</title>
<p>
- When you are designing a Component to be run from the command
+ When you are designing a component to be run from the command
line (or directly by the operating system), try to separate
- the main function from the Component itself. This is imperative
+ the main function from the component itself. This is imperative
in order to maintain the passive API of Avalon. By designing
- you Component in the manner stated in the previous section,
+ your component in the manner stated in the previous section,
you have effectively minimized what the main function has to
do.
</p>
<p>
Follow the practice of having an object dedicated to the main
function that includes the parsing of the command line parameters
- and initialization of the Component. When the Component is used
+ and initialization of the component. When the component is used
the exact same way in every context (including the command line),
you minimize the number of locations to look while debugging.
</p>
<note>
A common mistake is to combine the main function in the
- implementation of the Component. This requires violating the
+ implementation of the component. This requires violating the
contracts and principles that Avalon is built upon. This
violation of the pattern of "Inversion of Control" is
aptly dubbed "Subversion of Control" (thanks to Steven Coffman
1.2 +3 -3
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/getting-started.xml
Index: getting-started.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/getting-started.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- getting-started.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ getting-started.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -10,15 +10,15 @@
<body>
<section>
<title>Introduction</title>
- <p>If you are completely new to Avalon, the Framework subproject is not
+ <p>If you are completely new to Avalon, the Framework sub-project is not
the easiest place to start. We suggest you take a look at the
- <link href="http://avalon.apache.org/phoenix/getting-started.html";>Avalon
Phoenix getting started document</link>
+ <link href="http://avalon.apache.org/phoenix/getting-started.html";>Avalon
Phoenix Getting Started document</link>
first, as it will take you through downloading, installing and then
running something (a very simple server program) much more concrete.</p>
<p>Probably the next smart step is to learn by example. Take a look at
one or two of the <link
href="http://avalon.apache.org/apps/index.html";>applications</link>
- that use avalon and at how well these are set up, and at some of the
+ that use Avalon and at how well these are set up, and at some of the
available <link
href="http://avalon.apache.org/excalibur/index.html";>components (in Excalibur)</link>
and <link href="http://avalon.apache.org/cornerstone/index.html";>services (in
Cornerstone)</link>
Avalon offers.</p>
1.2 +50 -50
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-cop-in-avalon.xml
Index: guide-cop-in-avalon.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-cop-in-avalon.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- guide-cop-in-avalon.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ guide-cop-in-avalon.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -12,7 +12,7 @@
<section>
<title>Components in Avalon</title>
<p>
- At the core of the Avalon framework is the Component. We define it as "a
+ At the core of the Avalon framework is the component. We define it as "a
passive entity that performs a specific role". This is important to grasp
because it requires a specific way of thinking.
</p>
@@ -28,13 +28,13 @@
<section>
<title>A specific Role</title>
<p>
- The concept of roles come from the theater. A play, musical,
+ The concept of roles comes from the theater. A play, musical,
or movie will have a certain number of roles that actors play.
Although there never seems to be a shortage of actors, there
are a finite number of roles. I am not going to make reference
to different types of roles at this point, but simply bring
the concept to light. The function or action of a role is
- defined by it's script.
+ defined by its script.
</p>
<p>
We are introducing this concept now because you need to have it
@@ -43,12 +43,12 @@
"cast" of components so to speak.
</p>
<p>
- For each role, you need to specify it's script, or interface to
+ For each role, you need to specify its script, or interface to
the rest of the system. To be honest the interface is not enough.
There are specific contracts that you must define and keep in mind
when you specify your interfaces. In other words, what users
- of the Component must provide, and what the Component produces.
- When the interface and contract are defined, you can work on your
+ of the component must provide, and what the component produces.
+ When the interfaces and contracts are defined, you can work on your
implementation.
</p>
</section>
@@ -59,20 +59,20 @@
<title>The Component</title>
<p>
John Donne wrote, "No man is an island." to communicate that we
- are all interdependent. The same is true for the Component. That
- is why there are different concerns regarding the Component. In
+ are all interdependent. The same is true for the component. That
+ is why there are different concerns regarding the component. In
the section on roles we specified one of the concerns: the role.
The concerns directly supported by the Avalon Framework are:
configuration, external component use, management, and execution.
</p>
<note>
- We used to have an marker interface Component. This has been deprecated
+ We used to have a marker interface component. This has been deprecated
because requiring all components extend this interface makes
integrating Avalon with other component systems like
<link href="http://www.corba.org";>CORBA</link> very cumbersome.
</note>
<p>
- As you might of guessed, each one of these concerns has a separate
+ As you might have guessed, each one of these concerns has a separate
interface that describes that concern. We will delve deeper into
the interfaces and the reasoning behind them in other sections. It
is important to know the order of precedence for the concerns so
@@ -98,8 +98,8 @@
<p>
The contract surrounding this order means that the methods defined
by each of those interfaces are called in a specific order by the object
- that created the Component. Each interface represents a narrow view
- of the Component or object being controlled.
+ that created the component. Each interface represents a narrow view
+ of the component or object being controlled.
</p>
<note>
Notice that each interface is separate from Component, so you can use
@@ -111,14 +111,14 @@
<title>The Composable</title>
<p>
In Avalon, Composable is defined as an active entity that controls
- or uses Components. Its best analogy is that of a musical composer.
- The musical composer chooses what instruments (Components) by their
+ or uses components. Its best analogy is that of a musical composer.
+ The musical composer chooses instruments (components) by their
role in the symphony (system) and tells them which notes to play.
</p>
<p>
The Avalon Composable follows the principles of Inversion of Control,
and is assigned a Component Manager. Within this section we will
- discuss how to look up specific Components, and then how to prepare
+ discuss how to look up specific components, and then how to prepare
the ComponentManager for the Composable.
</p>
<note>
@@ -135,20 +135,20 @@
<title>The Component Manager</title>
<p>
For the majority of all cases, you will need to use the ComponentManager
- get the instance of the Component you need. If you recall the discussion
- on Component Roles in the Component documentation, you already have
- a head start. In Avalon, Roles are defined by the work interface a
- Component has. A work interface is different from any other interface
- because it is the interface that defines the Component's Role. Composable
+ to get the instance of the component you need. If you recall the
discussion
+ on component roles in the component documentation, you already have
+ a head start. In Avalon, roles are defined by the work interface a
+ component has. A work interface is different from any other interface
+ because it is the interface that defines the component's role. Composable
and Component are concern interfaces because they address specific
- concerns about the Component.
+ concerns about the component.
</p>
<p>
- The ComponentManager has one method to retrieve all of your Components.
- The <code>lookup</code> method will look up the Component based on the
+ The ComponentManager has one method to retrieve all of your components.
+ The <code>lookup</code> method will look up the component based on the
fully qualified name (FQN) of the work interface (Role). It is important
to realize that the ComponentManager returns Components, and therefore
- you must recast the Component to the Role you need. See the following
+ you must recast the Component to the role you need. See the following
example:
</p>
<source>
@@ -156,26 +156,26 @@
lookup( "com.mycompany.myproject.MyComponent" );
</source>
<p>
- It is important to note that Role is not the same thing as functional
+ It is important to note that role is not the same thing as functional
equivalence. In other words, if you have a MailSpooler that is
functionally
equivalent to a FileStore (they do the same thing), it does not mean that
- they perform the same Role. The FileStore is used to store objects to
+ they perform the same role. The FileStore is used to store objects to
files, and the MailSpooler is used to temporarily store messages until
they are sent. Thus they are separate roles. Some containers require
that the interface name match the key used to lookup component. In this
- situation it you may need to create a new interface that does nothing
+ situation you may need to create a new interface that does nothing
more than extend another interface and add a new role.
</p>
</section>
<section>
<title>The Component Selector</title>
<p>
- Sometimes you will have several Components that function in the same role.
+ Sometimes you will have several components that function in the same role.
For those cases, you will use the ComponentSelector to choose the exact
one you need. The best way to describe its proper use is the scenario
- described here. You have several formatters that have the same Role:
+ described here. You have several formatters that have the same role:
to take an input document and format it according to the rules in the
- individual Component implementations. One formatter may take a text file
+ individual component implementations. One formatter may take a text file
and remove all tabs and replace them with four spaces. Another formatter
may reverse the formerly mentioned one. Yet another takes the text file
and formats it for a canvas object. For the Composable, it makes no
difference
@@ -183,12 +183,12 @@
</p>
<p>
Using the processing chain example in the previous paragraph, we realize
- the unsuitability of the ComponentManager for getting the right Component.
- The Component addresses the concern of one Component per role.
Fortunately,
- the ComponentSelector is a Component. That means we use the
ComponentManager
+ the unsuitability of the ComponentManager for getting the right component.
+ The component addresses the concern of one component per role.
Fortunately,
+ the ComponentSelector is a component. That means we use the
ComponentManager
to lookup the ComponentSelector. The ComponentSelector is designed to
choose
- the specific Component out of many that perform the <strong>same</strong>
- Role. The following code will help:
+ the specific component out of many that perform the <strong>same</strong>
+ role. The following code will help:
</p>
<source>
final ComponentSelector selector = (ComponentSelector)manager.
@@ -200,7 +200,7 @@
acts much like a hashtable lookup. Keep in mind that the implementation
of the
selector does not limit you to a hashtable lookup--you can dynamically
instantiate objects as well. It takes an object (a hint), and returns the
- specific Component based on that hint.
+ specific component based on that hint.
</p>
<note>
@@ -214,7 +214,7 @@
<title>When you are done with the Component</title>
<p>
Both the ComponentManager and the ComponentSelector require you to
- release your Component when you are done with it. The method used
+ release your component when you are done with it. The method used
to do this is "release". One way of handling this is to use the
try/catch/finally construct. For your convenience, the following
code can help:
@@ -237,8 +237,8 @@
}
</source>
<p>
- The reason for this is so that smart Component Managers that
- select Components from a pool can properly manage the resources.
+ The reason for this is so that smart component managers that
+ select components from a pool can properly manage the resources.
</p>
</section>
</section>
@@ -263,9 +263,9 @@
the default implementation will look in the parent ComponentManager.
</p>
<p>
- For the paranoid developer, the Cascading feature of the ComponentManager
+ For the paranoid developer, the cascading feature of the ComponentManager
can be seen as a security hole as opposed to a usability enhancement. You
- are free to create your own implementation that does not use the Cascading
+ are free to create your own implementation that does not use the cascading
feature--but you have to manually populate it with anything that would
have been in the parent ComponentManager that your child Composable needs.
Truth be told, there is very little risk due to the set-once contract for
@@ -276,36 +276,36 @@
<section>
<title>DefaultComponentSelector</title>
<p>
- The DefaultComponentSelector again is simply a Hashtable selection of
Components
+ The DefaultComponentSelector again is simply a Hashtable selection of
components
based on hints. It gives the method <code>put</code> to populate the
ComponentSelector.
The ComponentSelector does not have the cascading feature of the
ComponentManager,
- nor should it. A ComponentSelector simply holds a number of Components
that
+ nor should it. A ComponentSelector simply holds a number of components
that
implement the same role--there really is no need to cascade.
</p>
<p>
After the ComponentSelector is populated, you must put it in the
ComponentManager.
- Please use the role of the Component you are selecting, not the role of
the selector
+ Please use the role of the component you are selecting, not the role of
the selector
itself. An acceptable convention is to add the "Selector" name to the
end of the
- Role you are looking up. Just be consistent.
+ role you are looking up. Just be consistent.
</p>
</section>
</section>
<section>
<title>The Container</title>
<p>
- The Container is the entity that manages your Components. It handles
+ The container is the entity that manages your components. It handles
things like loading of configuration files, resolution of dependencies,
component management, component isolation, and lifecycle support.
</p>
<p>
- The Container is not formalized in the form of an interface or contract
+ The container is not formalized in the form of an interface or contract
within Avalon Framework, though it might be at some point in the
future.
The informal contract for the container is that it has the ability to
- host any fully avalon-framework compliant component. Most current
containers
- place additional requirments on the component.
+ host any fully Avalon-Framework compliant component. Most current
containers
+ place additional requirements on the component.
</p>
<p>
- For a list of containers implementations,
+ For a list of container implementations,
<link href="reference-containers.html">look here</link>.
</p>
</section>
1.2 +7 -7
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-cop-what-is.xml
Index: guide-cop-what-is.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-cop-what-is.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- guide-cop-what-is.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ guide-cop-what-is.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -13,24 +13,24 @@
<title>Introduction</title>
<p>
Component Oriented Programming, or COP for short, takes Object Oriented
- Programming one step further. Regular OOP organizes data object into
+ Programming one step further. Regular OOP organizes data objects into
entities that take care of themselves. There are many advantages to this
- approach. I'll assume that you, being a java programmer, are familiar
+ approach. I'll assume that you, being a Java programmer, are familiar
with those.
</p>
<p>
It also has a big limitation: that of object co-dependency. To remove that
- limitation, a more rigid idea had to be formalized: the Component. The key
+ limitation, a more rigid idea had to be formalized: the component. The key
difference between a regular object and a component is that a component is
completely replaceable.
</p>
</section>
<section>
-<title>COP is not just a buzzword</title>
+<title>COP is not just a Buzzword</title>
<p>
There is a lot of buzz in the industry touting Component Based Design
- (CBD). You will find, that the definition of a Component in Avalon
- is more formal than most companies' definition of a Component. Any
+ (CBD). You will find, that the definition of a component in Avalon
+ is more formal than most companies' definition of a component. Any
system developed with the principles of Avalon can claim CBD. In
fact the Avalon Framework formalizes CBD more rigidly than the marketing
definition. Do not be fooled though, CBD and COP aren't necessarily
@@ -38,7 +38,7 @@
designed and not how it is implemented. Component Oriented Programming,
on the other hand, refers to how a system is implemented and not how
it is designed. In practice, you can't implement COP without first
- designing with Components in mind.
+ designing with components in mind.
</p>
</section>
</body>
1.2 +9 -9
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-oop-best-practices.xml
Index: guide-oop-best-practices.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-oop-best-practices.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- guide-oop-best-practices.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ guide-oop-best-practices.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -2,7 +2,7 @@
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"document-v11.dtd">
<document>
<header>
- <title>Avalon Framework - Guide - OOP best practices</title>
+ <title>Avalon Framework - Guide - OOP best Practices</title>
<authors>
<person name="Leo Simons" email="[EMAIL PROTECTED]"/>
</authors>
@@ -21,7 +21,7 @@
</p>
<p>
- Note that a good knowledge of the basic OOP concepts is a requirment for
+ Note that a good knowledge of the basic OOP concepts is a requirement for
understanding any of this. Many books deal with this, one that is freely
available online is
<link href="http://www.mindview.net/Books/TIJ/";>
@@ -40,7 +40,7 @@
<p>
If you need additional functionality, either create proxy
objects that implement the interface, or add it by subclassing
- (hence the name "Recursion Introduction". Even if
+ (hence the name "Recursion Introduction"). Even if
there is no recursion happening, it appears to operate in the
same manner.
</p>
@@ -72,7 +72,7 @@
</p>
</section>
<section>
-<title>The Top of the Class Heirarchy Should be Abstract</title>
+<title>The Top of the Class Hierarchy Should be Abstract</title>
<p>
In many cases it is beneficial to provide an abstract base class
to extend for your specializations. The majority of the
@@ -132,13 +132,13 @@
<title>Send Messages to Components instead of to This</title>
<p>
The point of this point is that you want to build your framework
- based on Components, and not inheritance. Avalon takes this
+ based on components, and not inheritance. Avalon takes this
point to heart. In order to illustrate, I will give two examples
of the same thing. The scenario is that we have a data structure
that we want to output to an arbitrary format.
</p>
<p>
- In the following example, we will use the java <code>this</code>
+ In the following example, we will use the Java <code>this</code>
object and an inheritance based framework. As you can see, this
would be a bear to maintain, and it won't easily be extended.
</p>
@@ -158,7 +158,7 @@
}
</source>
<p>
- In the next example, we will use the Avalon Component based
+ In the next example, we will use the Avalon component based
architecture. There is a clean separation between the purpose
of the objects, and you can exchange and extend formatting
without worrying about any other concerns.
@@ -181,7 +181,7 @@
<p>
An inheritance based framework (White Box) can be converted
into a component based framework (Black Box) structure by
- replacing overridden methods by method calls (message sends)
+ replacing overridden methods with method calls (message sends)
to components. Component based architecture is much more
flexible in this regard.
</p>
@@ -191,7 +191,7 @@
<p>
Just because two methods share the same information within the
class does not mean that it should be done in that manner.
- Many times, that attribute that is shared should be passed
+ Many times, the attribute that is shared should be passed
as a parameter of the method instead of directly accessing
the attribute.
</p>
1.2 +4 -4
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-patterns-in-avalon.xml
Index: guide-patterns-in-avalon.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-patterns-in-avalon.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- guide-patterns-in-avalon.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ guide-patterns-in-avalon.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -12,7 +12,7 @@
<title>Getting Started with Patterns</title>
<p>
Avalon takes many design patterns and architectural mindsets, and
- implements the best ones for Servers. There are different kinds of
+ implements the best ones for servers. There are different kinds of
patterns that represent different aspects of Avalon. Avalon uses four
main conceptual patterns called Separation of Interface and
Implementation, Inversion of Control, Multi-Dimensional Separation
@@ -45,7 +45,7 @@
<title>Inversion of Control</title>
<p>
<strong>Summary:</strong> Avalon not only has an inheritance hierarchy, but also a
- Component hierarchy. In this hierarchy, the control of program flow is
+ component hierarchy. In this hierarchy, the control of program flow is
completely in the hands of the parent component(s), as soldiers in the
military take orders from their officers.
</p>
@@ -61,7 +61,7 @@
<p>
<strong>Summary:</strong> You just read the introduction about patterns before
reading about Avalon's patterns because that enables you to reuse the
- knowledge you gained about patterns in context other than that of
+ knowledge you gained about patterns in a context other than that of
Avalon. We do this with software as well.
</p>
<p>
@@ -78,7 +78,7 @@
Concerns. Many concerns cannot be centrally addressed using the standard
OOP mechanisms. Using AOP (which is an extension to OOP), we would be
able to do so in a simple fashion. As there is no good AOP facility
- in java, we use "aspect marker interfaces" and COP instead.
+ in Java, we use "aspect marker interfaces" and COP instead.
</p>
</section>
1.2 +24 -25
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-patterns-ioc-security.xml
Index: guide-patterns-ioc-security.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-patterns-ioc-security.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- guide-patterns-ioc-security.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ guide-patterns-ioc-security.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -15,8 +15,8 @@
In this context security is defined as protection of data, and
quality of service (QOS). Both of these fall under security because
a system must protect itself from these two forms of attack. When
- a company loses a system, they lose business, and the money they
- lose can reach scary amounts.
+ a company loses a system, it loses business, and the money it
+ loses can reach scary amounts.
</p>
<p>
For the purpose of this discussion, we will address the first
@@ -35,7 +35,7 @@
trusted system, authentication is as simple as grabbing a reference
to the object or entity you want to manipulate. However, sometimes
you have trusted systems running in hostile environments (e.g. the
- internet). In those cases you have to make sure that the entity
+ Internet). In those cases you have to make sure that the entity
is the correct one.
</p>
<p>
@@ -51,21 +51,21 @@
hoops to authenticate themselves.
</p>
<p>
- Currently, Avalon identifies Blocks as trusted parties. In other
+ Currently, Avalon identifies blocks as trusted parties. In other
words, the fact that they are installed correctly in the proper
directory is enough to mark them as authenticated. Much like a
good friend--you know them by their voice. Because of the architecture
- of Avalon, Blocks define their own authentication system. That
- means that whether the Block assumes all Components are trusted
+ of Avalon, blocks define their own authentication system. That
+ means that whether the block assumes all components are trusted
or it forces the blocks to authenticate themselves is up to the
block.
</p>
<p>
For systems that deal with sensitive information, authentication
- becomes more of an issue. You must validate that the Components
+ becomes more of an issue. You must validate that the components
in use are the ones you have authorized for use. The more open a
system is, the more authentication and authorization play an important
- role. If you have Components that are transmitted over some form
+ role. If you have components that are transmitted over some form
of communications system (wire, air, etc.) you must verify that
they are who they say they are.
</p>
@@ -78,17 +78,17 @@
<section>
<title>Authorization</title>
<p>
- Once a Component has been authenticated (in other words it's identity
+ Once a component has been authenticated (in other words its identity
has been authoritatively validated), then you must decide what access
- it has to your systems. A fully trusted Component can do what it likes.
- An untrusted Component must be denied functions it is not allowed.
+ it has to your systems. A fully trusted component can do what it likes.
+ An untrusted component must be denied functions it is not allowed.
</p>
<p>
Authorization is part of the architecture, but is significant enough
- to warrant it's own concern. The best rule of thumb is to hide access
- to everything unless the Component is trusted. When hiding is not
+ to warrant its own concern. The best rule of thumb is to hide access
+ to everything unless the component is trusted. When hiding is not
an option, then you have to resort to denying access. For the security
- conscious, all denied accesses should be logged along with the Component's
+ conscious, all denied accesses should be logged along with the component's
identifier.
</p>
</section>
@@ -96,7 +96,7 @@
<title>Architecture</title>
<p>
Avalon already has the framework for the proper secure architecture.
- With proper planning, security can be added without recoding the
Components.
+ With proper planning, security can be added without recoding the
components.
However there are some rules of thumb for paranoid programming.
</p>
<ol>
@@ -106,11 +106,11 @@
Oriented Programming (COP).
</li>
<li>
- Any Component that originates from your own jar should be trusted--you
+ Any component that originates from your own jar should be trusted--you
provided it after all.
</li>
<li>
- Any Component that originates from another source, and especially over
+ Any component that originates from another source, and especially over
a wire, should be treated with suspicion. Authenticate it, and if it
checks out, trust it. Otherwise, don't give it access--you don't know
where it's been or who created it.
@@ -134,8 +134,8 @@
<p>
Our customer, a well known corporation whom I will call ACME for
anonymity, is in custody of sensitive information. Product movement data,
- financial data, and demographic data are all stored in one of a couple
- huge server farms. Our application was to reside in the De-Militarize
+ financial data, and demographic data are all stored in one of a couple of
+ huge server farms. Our application was to reside in the De-Militarized
Zone (DMZ), and talk to a database behind the firewall. When they
discovered
that the application server we chose required Remote Procedure Calls (the
subject of many CERT advisories in the Unix world), we hit a brick wall.
Our
@@ -165,18 +165,17 @@
conditioners to reduce the Electro-Magnetic Interference (EMI) coming from
the
power line feedback of the computers. His rationalization was that he was
positive KGB agents had the technology that they could read the EMI
interference
- on the power lines and read the bits on the computers. In hind sight this is
+ on the power lines and read the bits on the computers. In hindsight this is
improbable; no one can identify the bits travelling on a computer from EMI in
the
power lines due to the level of noise (clocks, addressing lines,
<em>encrypted data</em>, and other computers on the network).
</p>
<p>
- The security industry have a general rule of thumb to ensure that you don't
spend
- too much time in this area: The cost of cracking the server should
- be more than
+ The security industry has a general rule of thumb to ensure that you don't
spend
+ too much time in this area: The cost of cracking the server should be more
than
the information that is protected is worth. Basically it boils down to this:
- sites like Slashdot and SourceForge do not require as much security as a Bank.
- Protecting free information is not as critical as protecting peoples bank
accounts.
+ sites like Slashdot and SourceForge do not require as much security as a bank.
+ Protecting free information is not as critical as protecting people's bank
accounts.
I am not minimizing the contributions of the aforementioned sites to the world
as a whole, but people become much more agitated if their bank account is wiped
clean than if their news article is defaced. This is not to say that if you
are
1.2 +5 -5
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-patterns-ioc.xml
Index: guide-patterns-ioc.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-patterns-ioc.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- guide-patterns-ioc.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ guide-patterns-ioc.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -52,10 +52,10 @@
<p>
This is probably the clearest parallel to <em>Inversion
of Control</em>. The military provides each new recruit
- with the basic things they need to operate at their rank,
+ with the basic things he needs to operate at his rank,
and issues commands that recruit must obey. The same
principle applies in code. Each component is given the
- provisions they need to operate by the instantiating
+ provisions it needs to operate by the instantiating
entity (i.e. Commanding Officer in this analogy). The
instantiating entity then acts on that component how it
needs to act.
@@ -100,12 +100,12 @@
</source>
<p>
The parent of MyComponent instantiates MyComponent, sets the
- Logger, and calls myMethod. The Component is not autonomous,
- and is given a Logger that has been configured by the parent.
+ Logger, and calls myMethod. The component is not autonomous,
+ and is given a logger that has been configured by the parent.
</p>
<p>
The MyComponent class has no state apart from the parent, and
- has no way of obtaining a reference to the Logger implementation
+ has no way of obtaining a reference to the logger implementation
without the parent giving it the implementation it needs.
</p>
</section>
1.2 +7 -7
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-patterns-soc.xml
Index: guide-patterns-soc.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-patterns-soc.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- guide-patterns-soc.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ guide-patterns-soc.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -11,7 +11,7 @@
<section>
<title>Introduction</title>
<p>
- The concept of using different points of view within the the system
+ The concept of using different points of view within the system
goes a long way in the overall comprehension of the system.
</p>
<p>You can get more formal information in this paper:
@@ -23,18 +23,18 @@
"Separation of Concerns" in its simplest form is separating
a problem into different points of view. For instance, the documentation
uses the "Separation of Concerns" pattern to make the documents
- comprehensible (we have separate documents for Developers, Administrators,
- and Block Implementers). The documents also use the pattern with XML and
+ comprehensible (we have separate documents for developers, administrators,
+ and block implementers). The documents also use the pattern with XML and
XSL so that the look is separated from the content. Either can change
without breaking the other.
</p>
<p>
This pattern is less clear to point out in the code, however the concept
is evident. There are several interfaces included in Avalon that
identify
- an object's role within the system. For instance, all Components have
certain
+ an object's role within the system. For instance, all components have
certain
contracts -- therefore any object that implements the Component interface
- must comply with those Contracts. This allows developers to manipulate
- Components using a standard interface, without worrying about the
semantics
+ must comply with those contracts. This allows developers to manipulate
+ components using a standard interface, without worrying about the
semantics
of the implementation. They are separate concerns.
</p>
</section>
@@ -49,7 +49,7 @@
Every time you use interfaces within Object Oriented Programming (OOP),
you are using the "Separation of Concerns" Pattern. The interface
separates the concern of the implementation from the concern of the user
- of the interface. For example, every Object that can be configured
+ of the interface. For example, every object that can be configured
implements the Configurable interface. The contract surrounding the
Configurable interface is that the instantiator of the object passes a
Configuration object to the Configurable object (see "Inversion
1.2 +12 -12
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-patterns-soii.xml
Index: guide-patterns-soii.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-patterns-soii.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- guide-patterns-soii.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ guide-patterns-soii.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -32,12 +32,12 @@
<li>it forces you to decouple different
modules/components/objects</li>
<li>if specified correctly allows you to easily change the
implementation of
the interface/contract in the future</li>
- <li>makes it possible for a user to read documentation about interface
+ <li>makes it possible for a user to read documentation about the
interface
without having the implementation details clutter up their
perception</li>
<li>increases the possibility of reuse in a larger application</li>
</ol>
<p>
- If you are building objects with the aim of reuse then [2] is important
but
+ If you are building objects with the aim of reuse then [3] is important
but
most people don't build for reuse (and most XP advocates say you should
just
plan to use not reuse) and thus [1] and [2] are more important. If you
feel
like documenting that and expanding this then feel free to.
@@ -77,7 +77,7 @@
<section>
<title>History</title>
<p>
- We are referring to this pattern at <strong>interface/impl
separation</strong>.
+ We are referring to this pattern as <strong>interface/impl
separation</strong>.
Wiley's Patterns in Java book refers to it simply as 'Interface', but we
feel
that the word interface is overloaded enough in English and computing.
</p>
@@ -86,7 +86,7 @@
this too could be confusing as the aforementioned SAX is not quite a
pure set of interfaces. It has a static factory that thunks in an
implementation that all subsequent calls to the factory method will be
- forced to use. See Anti-patterns below.
+ forced to use. See Anti-Patterns below.
</p>
<p>
Better might be 'separation of implementation and the interface/contract'
as
@@ -95,13 +95,13 @@
</section>
</section>
<section>
-<title>Related topics</title>
+<title>Related Topics</title>
<section>
-<title>Implementation hiding</title>
+<title>Implementation Hiding</title>
<p>
Once a tool is split into interface and impl, it is possible for a
container
to hide the implementation. Most containers already use dynamic proxys
- (Available in the JDK since 1.3), but we are talking about having the
classes
+ (available in the JDK since 1.3), but we are talking about having the
classes
of the implementation hidden from classes using the interface.
</p>
<p>
@@ -126,20 +126,20 @@
<section>
<title>Kernel, Client API, Hosted Components</title>
<p>
- This is building the previous section, and in short is referred to as
K/CAPI/HC.
- Basically the Kernel mounts hosted components and satisfies their need
for a
+ This is building on the previous section, and in short is referred to as
K/CAPI/HC.
+ Basically the kernel mounts hosted components and satisfies their need
for a
client API. However the kernel wants to hide its implementation from the
hosted
components.
</p>
<p>
- An EJB container is another good example of this. EntityBean,
SessionBean etc is
+ An EJB container is another good example of this. EntityBean,
SessionBean etc. is
the client API. The hosted components are the beans, and the container
has a
kernel. It builds a complex tree of classloaders to separate its
implementation,
the client API, the JDK's runtime jar (that always being in the system or
primordial classloader), and the hosted components.
</p>
<p>
- The central message of this is that it you have interface/impl separated
your
+ The central message of this is that if you have interface/impl separated
your
tool, and are doing tricky things with more classloaders in the
implementation,
please make sure you do not assume that the parent classloader of any
classloader
is the system classloader. If your reusable tool has been taken by
another team
@@ -148,7 +148,7 @@
</p>
</section>
<section>
-<title>Anti-patterns</title>
+<title>Anti-Patterns</title>
<p>
SAX, mentioned in multiple contexts in this document, is also an example
of
where the design can go wrong. The Factory is static (that in itself is
an
1.2 +7 -7
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-patterns-what-are.xml
Index: guide-patterns-what-are.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-patterns-what-are.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- guide-patterns-what-are.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ guide-patterns-what-are.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -14,18 +14,18 @@
<p>
I highly recommend reading the
<link
href="http://www6.software.ibm.com/developerworks/education/j-patterns/index.html";>
- "Java Design patterns 101"
+ "Java Design Patterns 101"
</link> tutorial, and its follow-up
<link
href="http://www6.software.ibm.com/developerworks/education/j-patterns201/index.html";>
- "Java Design patterns 201"
- </link>, if you are unfamiliar with the concept of Design Patterns (and
+ "Java Design Patterns 201"
+ </link>, if you are unfamiliar with the concept of design patterns (and
see below for more information). Note that you have to register at the
IBM DeveloperWorks site in order to read these, but that's a good idea
anyway.
</p>
</section>
<section>
-<title>Where to learn more</title>
+<title>Where to Learn more</title>
<p>
You can find more information about patterns from the following links:
</p>
@@ -34,15 +34,15 @@
</li>
<li>
<link
href="http://www6.software.ibm.com/developerworks/education/j-patterns/index.html";>
- "Java Design patterns 101"
+ "Java Design Patterns 101"
</link> at DeveloperWorks</li>
<li>
<link
href="http://www6.software.ibm.com/developerworks/education/j-patterns201/index.html";>
- "Java Design patterns 201"
+ "Java Design Patterns 201"
</link> at DeveloperWorks</li>
<li>
<link href="http://cseng.aw.com/book/0,3828,0201633612,00.html";>
- "Java Design patterns: Elements of Reusable Object-Oriented Software"
+ "Java Design Patterns: Elements of Reusable Object-Oriented Software"
</link> by the GoF (printed book)</li>
</ol>
</section>
1.2 +4 -4
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-where-to-go-from-here.xml
Index: guide-where-to-go-from-here.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/guide-where-to-go-from-here.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- guide-where-to-go-from-here.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ guide-where-to-go-from-here.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -2,7 +2,7 @@
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.1//EN"
"document-v11.dtd">
<document>
<header>
- <title>Avalon Framework - Guide - Where to go next</title>
+ <title>Avalon Framework - Guide - Where to Go next</title>
<authors>
<person name="Leo Simons" email="[EMAIL PROTECTED]"/>
</authors>
@@ -18,15 +18,15 @@
</p>
</section>
<section>
-<title>Creating components</title>
+<title>Creating Components</title>
<p>
After all the information in this guide has sunk in, you're probably
- itching to write an Avalon Component. Our
+ itching to write an Avalon component. Our
<link href="http://avalon.apache.org/developing/index.html";>Developing with
Avalon guide
</link> takes you through doing just that. You can download it as a PDF
and read at your leisure (it comes down to 56 printed pages). If that's
too much for you, we suggest you get the latest
- <link href="http://avalon.apache.org/excalibur/index.html";>excalibur</link>
release and
+ <link href="http://avalon.apache.org/excalibur/index.html";>Excalibur</link>
release and
take those components as an example. One application that uses a lot of
those components and is in widespread daily use is
<link href="http://xml.apache.org/cocoon";>Cocoon</link>.
1.2 +9 -9
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/index.xml
Index: index.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/index.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ index.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -11,7 +11,7 @@
<section>
<title>Introduction</title>
<p>
- The Avalon framework consists of interfaces
+ The Avalon Framework consists of interfaces
that define relationships between commonly used application components,
best-of-practice pattern enforcements, and several
lightweight convenience implementations of the generic components.
@@ -19,10 +19,10 @@
<p>
If that sounds a bit abstract to you, we suggest you start by reading
the guide (see below). If you want to see the code first, either
- <link
href="http://jakarta.apache.org/builds/jakarta-avalon/release/framework";>Download</link>
+ <link
href="http://jakarta.apache.org/builds/jakarta-avalon/release/framework";>download</link>
it or
<link href="http://jakarta.apache.org/site/cvsindex.html";>get it from
CVS</link>.
- The <link href="getting-started.html">Getting started</link> document
+ The <link href="getting-started.html">Getting Started</link> document
provides more pointers.
</p>
</section>
@@ -55,13 +55,13 @@
<title>Contents</title>
<ol>
<li>
-<link href="guide-oop-best-practices.html">OOP best practices</link>
+<link href="guide-oop-best-practices.html">OOP best Practices</link>
</li>
<li>
-<link href="guide-patterns-what-are.html">What are design patterns?</link>
+<link href="guide-patterns-what-are.html">What are Design Patterns?</link>
</li>
<li>
-<link href="guide-patterns-in-avalon.html">Design patterns in Avalon</link>
+<link href="guide-patterns-in-avalon.html">Design Patterns in Avalon</link>
</li>
<li>
<link href="guide-cop-what-is.html">What is Component-Oriented Programming?</link>
@@ -70,7 +70,7 @@
<link href="guide-cop-in-avalon.html">COP in Avalon</link>
</li>
<li>
-<link href="guide-where-to-go-from-here.html">Where to go next</link>
+<link href="guide-where-to-go-from-here.html">Where to Go next</link>
</li>
</ol>
</section>
@@ -80,8 +80,8 @@
<p>
Besides the
<link href="http://avalon.apache.org/api/index.html";>Javadocs</link>, we
have the
- <link href="reference-the-lifecycle.html">Lifecycle specification</link>
and the
- <link href="reference-containers.html">List of containers</link>.
+ <link href="reference-the-lifecycle.html">Lifecycle Specification</link>
and the
+ <link href="reference-containers.html">List of Containers</link>.
</p>
</section>
</body>
1.2 +8 -8
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/reference-containers.xml
Index: reference-containers.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/reference-containers.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- reference-containers.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ reference-containers.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -25,7 +25,7 @@
<title>Avalon Phoenix</title>
<p>
This is a sister project to Avalon Framework. It provides an environment
- for launching of multiple, isolate, more or less unrestricted server
applications
+ for launching multiple, isolated, more or less unrestricted server
applications
as hosted components. These can be applications like a web server, RDBMS or
EJB server. It provides many advanced features like automatic management, at
the
cost of a bit of complexity.
@@ -44,8 +44,8 @@
<p>
Tweety is almost the opposite of Phoenix. It is a recent development and
written
exclusively as a teaching tool. It has no features whatsoever besides basic
support
- for the avalon lifecycle. This results in a complete distribution the size of
the
- phoenix bootstrapper.
+ for the Avalon lifecycle. This results in a complete distribution the size of
the
+ Phoenix bootstrapper.
See <link href="http://avalon.apache.org/excalibur/tweety";>Tweety</link>
</p>
</section>
@@ -69,7 +69,7 @@
<p>
This is used by various applications like Cocoon. Cocoon is run inside the
Sun specified servlet context of a web-app. It is designed for such
- Servlet-context reuse. ECM is the most stable of the containers (it is the
+ servlet-context reuse. ECM is the most stable of the containers (it is the
only one with a stable release); it is also arguably the worst design.
See <link href="http://avalon.apache.org/excalibur/component/";>ECM</link>.
</p>
@@ -77,7 +77,7 @@
<section>
<title>Fortress</title>
<p>
- Fortress is ment as a future replacement of ECM. It fixes several of ECMs
flaws
+ Fortress is meant as a future replacement of ECM. It fixes several of
ECMs flaws
like a mixup of concerns. It is built to be very extensible, and it includes
support for custom lifecycle extensions. Fortress is still pre-alpha.
See <link
href="http://avalon.apache.org/excalibur/fortress/";>Fortress</link>.
@@ -98,14 +98,14 @@
<title>Plexus</title>
<p>
Plexus is a container under development that will become the basis of the
- services framework for a sister project to avalon,
+ services framework for a sister project to Avalon,
<link href="http://jakarta.apache.org/turbine";>Turbine</link>.
</p>
<p>
See <link
href="http://tambora.zenplex.org/cgi-bin/cvsweb.cgi/plexus/";>Plexus</link>.
</p>
<note>
- Plexus is being developed outside of avalon itself as an external project.
+ Plexus is being developed outside of Avalon itself as an external project.
</note>
</section>
<section>
@@ -120,7 +120,7 @@
See <link href="http://eob.sourceforge.net/";>EOB</link>.
</p>
<note>
- EOB is an being developed outside of avalon itself as an external project.
+ EOB is an being developed outside of Avalon itself as an external project.
</note>
</section>
</section>
1.2 +7 -7
jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/reference-the-lifecycle.xml
Index: reference-the-lifecycle.xml
===================================================================
RCS file:
/home/cvs/jakarta-avalon/proposal/framework-forrest/src/documentation/content/xdocs/reference-the-lifecycle.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- reference-the-lifecycle.xml 29 Jan 2003 14:32:05 -0000 1.1
+++ reference-the-lifecycle.xml 3 Feb 2003 15:36:00 -0000 1.2
@@ -27,7 +27,7 @@
<link href="reference-containers.html">Containers</link>.
</p>
<p>
- The lifecyle methods from Avalon Framework sub-project are designed to be
+ The lifecyle methods from the Avalon Framework sub-project are designed to
be
used by just about any component hosted by any container. Of course, the
API
in question may well require additional interfaces for strongly typed
functionality, but these interfaces should negate the need for any
duplication
@@ -39,7 +39,7 @@
<p>
The lifecycle of a component specifies the methods that can be called on it,
and the order in which this may happen. Some methods can be called only once
- in a specific <code>Phase</code> of a component its lifecycle, others may
+ in a specific <code>phase</code> of a component's lifecycle, others may
be called multiple times. These methods are called the lifecycle methods.
</p>
<p>
@@ -50,7 +50,7 @@
</p>
</section>
<section>
-<title>The Lifecycle interfaces</title>
+<title>The Lifecycle Interfaces</title>
<p>
A component exposes its lifecycle methods by implementing the lifecycle
interfaces. Each of these defines one or more methods that represent a
@@ -80,7 +80,7 @@
</note>
</section>
<section>
-<title>Phase order</title>
+<title>Phase Order</title>
<p>
The order in which the various lifecycle methods are called is very
specific.
While none are required (it is possible to have a component implementing
@@ -89,7 +89,7 @@
a few examples.
</p>
<section>
-<title>simple examples</title>
+<title>Simple Examples</title>
<p>The lifecycle of a component implementing only Configurable for
example will be:</p>
<ol>
@@ -105,7 +105,7 @@
</ol>
</section>
<section>
-<title>complete</title>
+<title>Complete</title>
<p>
If a component implements more than one interface the order of
the events (service, configure etc.) follow a specific order. A component
@@ -178,7 +178,7 @@
The methods suspend() and resume() are not guaranteed to be called at all,
even when implemented. They can be called more than once, but only after
one another and between start() and stop(). The reason they exist is so
- the container can notify the component it needs to come to temporary stop
+ the container can notify the component it needs to temporarily stop
any operations. The container may need to perform some synchronized
operation
on one of the components used by this component, or it may wish to call
any
of the following methods, which can also be called zero or more times,
and
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
