You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by ha...@apache.org on 2002/09/07 10:49:26 UTC
cvs commit: jakarta-avalon/src/xdocs/framework reference-the-lifecycle.xml
hammant 2002/09/07 01:49:26
Modified: src/xdocs/framework reference-the-lifecycle.xml
Log:
Words on Serviceable
Revision Changes Path
1.4 +25 -25 jakarta-avalon/src/xdocs/framework/reference-the-lifecycle.xml
Index: reference-the-lifecycle.xml
===================================================================
RCS file: /home/cvs/jakarta-avalon/src/xdocs/framework/reference-the-lifecycle.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- reference-the-lifecycle.xml 5 Aug 2002 13:23:59 -0000 1.3
+++ reference-the-lifecycle.xml 7 Sep 2002 08:49:26 -0000 1.4
@@ -14,9 +14,9 @@
<body>
<s1 title="Introduction">
<p>
- A Component lives within something called a container. The contract between a
- container and a contained Component is simple: the container is required to
- take a Component through what is called its <strong>lifecycle</strong>.
+ A component lives within something called a container. The contract between a
+ container and a contained component is simple: the container is required to
+ take a component through what is called its <strong>lifecycle</strong>.
</p>
<p>
The Avalon project provides an
@@ -37,9 +37,9 @@
</s1>
<s1 title="The Lifecycle">
<p>
- The lifecycle of a Component specifies the methods that can be called on it,
+ 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 its lifecycle, others may
be called multiple times. These methods are called the lifecycle methods.
</p>
<p>
@@ -51,14 +51,14 @@
</s1>
<s1 title="The Lifecycle interfaces">
<p>
- A Component exposes its lifecycle methods by implementing the lifecycle
+ A component exposes its lifecycle methods by implementing the lifecycle
interfaces. Each of these defines one or more methods that represent a
- specific Phase in a Component's lifecycle. The defined interfaces are:
+ specific phase in a component's lifecycle. The defined interfaces are:
</p>
<ol>
<li>LogEnabled</li>
<li>Contextualizable</li>
- <li>Composable</li>
+ <li>Serviceable (replacement for Composable)</li>
<li>Configurable</li>
<li>Parameterizable</li>
<li>Initializable</li>
@@ -74,37 +74,37 @@
<note>
<strong>Note:</strong>java.lang.Runnable has also been in use as a lifecycle
interface. This is not recommended and is not supported by Avalon. Instead,
- the run() method is the responsibility of the Component itself. If you wish
+ the run() method is the responsibility of the component itself. If you wish
to use it, call it from within start() or another method.
</note>
</s1>
<s1 title="Phase order">
<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
+ While none are required (it is possible to have a component implementing
none of the lifecycle methods, although the use of that would be limited),
some can only be used when others are as well. This is best explained using
a few examples.
</p>
<s2 title="simple examples">
- <p>The lifecycle of a <code>Component</code> implementing only Configurable for
+ <p>The lifecycle of a component implementing only Configurable for
example will be:</p>
<ol>
<li>constructor</li>
<li>configure</li>
<li>finalize</li>
</ol>
- <p>The lifecycle of a <code>Component</code> implementing only Composable will be:</p>
+ <p>The lifecycle of a component implementing only Serviceable will be:</p>
<ol>
<li>constructor</li>
- <li>compose</li>
+ <li>service</li>
<li>finalize</li>
</ol>
</s2>
<s2 title="complete">
<p>
- If a <code>Component</code> implements more than one interface the order of
- the events (compose, configure etc.) follow a specific order. A Component
+ If a component implements more than one interface the order of
+ the events (service, configure etc.) follow a specific order. A component
implementing all above interfaces (including Runnable) will follow these
specific paths.
</p>
@@ -114,7 +114,7 @@
<ol>
<li>constructor <strong>as a consequence of instantiation</strong></li>
<li>contextualize</li>
- <li>compose</li>
+ <li>service or compose</li>
<li>configure</li>
<li>parameterize</li>
<li>initialize</li>
@@ -143,11 +143,11 @@
<s2 title="Phases executed once">
<p>
These lifecycle methods are only called once in the entire life of a
- Component:
+ component:
</p>
<ul>
<li>contextualize</li>
- <li>compose</li>
+ <li>service</li>
<li>configure</li>
<li>parameterize</li>
<li>initialize</li>
@@ -169,9 +169,9 @@
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 come to temporary 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
+ 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
only between a suspend() and a resume().
</p>
@@ -186,12 +186,12 @@
<s2 title="The Command Pattern">
<p>
The most advanced, most complicated and most flexible option is to use
- the Command pattern by having your Component implement the Commandable
+ the Command pattern by having your component implement the Commandable
interface. This is experimental; you'll find the Commandable and its
related classes in the excalibur package.
</p>
<p>
- It is recommended that if your Component implements Commandable, it should
+ It is recommended that if your component implements Commandable, it should
not implement Executable or Interruptable. When you do choose to combine the
two, the order in which the different steps must happen is very specific:
<code>
@@ -218,8 +218,8 @@
</p>
<p>
The advantage of using Commands is that you can have multiple processes running
- outside your Component that can manipulate it. These will run until completion
- even if you Component has already been disposed of.
+ outside your component that can manipulate it. These will run until completion
+ even if you component has already been disposed of.
</p>
<p>
You should note that the Command interface we use extends Runnable, which means
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon/src/xdocs/framework reference-the-lifecycle.xml
Posted by Peter Donald <pe...@apache.org>.
On Sat, 7 Sep 2002 18:54, Paul Hammant wrote:
> Is everyone happy with this change?
>
> I have..
>
> 1) dropped the case of most usages of Component.
> 2) Refered to Serviceable where Composable was used solely.
+1
> It looks like Reserviceable is missing. There is a Recomposable.
I think it was deliberate. We have never really defined what the re* methods
do or how they are supposed to act. If you look in our CVS I don't think you
will find any instances where any re* is ever used. I suspect it would be
good to elide until there is a clear and present need for it and multiple
containers implement it.
> Thoughts?
>
> Regards,
>
> - Paul
>
> >hammant 2002/09/07 01:49:26
> >
> > Modified: src/xdocs/framework reference-the-lifecycle.xml
> > Log:
> > Words on Serviceable
> >
> > Revision Changes Path
> > 1.4 +25 -25
> > jakarta-avalon/src/xdocs/framework/reference-the-lifecycle.xml
> >
> > Index: reference-the-lifecycle.xml
> > ===================================================================
> > RCS file:
> > /home/cvs/jakarta-avalon/src/xdocs/framework/reference-the-lifecycle.xml,
> >v retrieving revision 1.3
> > retrieving revision 1.4
> > diff -u -r1.3 -r1.4
> > --- reference-the-lifecycle.xml 5 Aug 2002 13:23:59 -0000 1.3
> > +++ reference-the-lifecycle.xml 7 Sep 2002 08:49:26 -0000 1.4
> > @@ -14,9 +14,9 @@
> > <body>
> >
> > <s1 title="Introduction">
> >
> > <p>
> >
> > - A Component lives within something called a container. The
> > contract between a
> >
> > - container and a contained Component is simple: the container is
> > required to
> >
> > - take a Component through what is called its
> > <strong>lifecycle</strong>.
> >
> > + A component lives within something called a container. The
> > contract between a
> >
> > + container and a contained component is simple: the container is
> > required to
> >
> > + take a component through what is called its
> > <strong>lifecycle</strong>.
> >
> > </p>
> >
> > <p>
> >
> > The Avalon project provides an
> >
> > @@ -37,9 +37,9 @@
> > </s1>
> >
> > <s1 title="The Lifecycle">
> >
> > <p>
> >
> > - The lifecycle of a Component specifies the methods that can be
> > called on it,
> >
> > + 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 its lifecycle,
> > others may
> >
> > be called multiple times. These methods are called the
> > lifecycle methods.
> >
> > </p>
> >
> > <p>
> >
> > @@ -51,14 +51,14 @@
> > </s1>
> >
> > <s1 title="The Lifecycle interfaces">
> >
> > <p>
> >
> > - A Component exposes its lifecycle methods by implementing the
> > lifecycle
> >
> > + A component exposes its lifecycle methods by implementing the
> > lifecycle
> >
> > interfaces. Each of these defines one or more methods that
> > represent a
> >
> > - specific Phase in a Component's lifecycle. The defined
> > interfaces are:
> >
> > + specific phase in a component's lifecycle. The defined
> > interfaces are:
> >
> > </p>
> >
> > <ol>
> >
> > <li>LogEnabled</li>
> >
> > <li>Contextualizable</li>
> >
> > - <li>Composable</li>
> >
> > + <li>Serviceable (replacement for Composable)</li>
> >
> > <li>Configurable</li>
> >
> > <li>Parameterizable</li>
> >
> > <li>Initializable</li>
> >
> > @@ -74,37 +74,37 @@
> > <note>
> >
> > <strong>Note:</strong>java.lang.Runnable has also been in use
> > as a lifecycle
> >
> > interface. This is not recommended and is not supported by
> > Avalon. Instead,
> >
> > - the run() method is the responsibility of the Component itself.
> > If you wish
> >
> > + the run() method is the responsibility of the component itself.
> > If you wish
> >
> > to use it, call it from within start() or another method.
> >
> > </note>
> >
> > </s1>
> >
> > <s1 title="Phase order">
> >
> > <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
> >
> > + While none are required (it is possible to have a component
> > implementing
> >
> > none of the lifecycle methods, although the use of that would
> > be limited),
> >
> > some can only be used when others are as well. This is best
> > explained using
> >
> > a few examples.
> >
> > </p>
> >
> > <s2 title="simple examples">
> >
> > - <p>The lifecycle of a <code>Component</code> implementing only
> > Configurable for
> >
> > + <p>The lifecycle of a component implementing only Configurable
> > for
> >
> > example will be:</p>
> >
> > <ol>
> >
> > <li>constructor</li>
> >
> > <li>configure</li>
> >
> > <li>finalize</li>
> >
> > </ol>
> >
> > - <p>The lifecycle of a <code>Component</code> implementing only
> > Composable will be:</p>
> >
> > + <p>The lifecycle of a component implementing only Serviceable
> > will be:</p>
> >
> > <ol>
> >
> > <li>constructor</li>
> >
> > - <li>compose</li>
> >
> > + <li>service</li>
> >
> > <li>finalize</li>
> >
> > </ol>
> >
> > </s2>
> >
> > <s2 title="complete">
> >
> > <p>
> >
> > - If a <code>Component</code> implements more than one
> > interface the order of
> >
> > - the events (compose, configure etc.) follow a specific order.
> > A Component
> >
> > + If a component implements more than one interface the order
> > of
> >
> > + the events (service, configure etc.) follow a specific order.
> > A component
> >
> > implementing all above interfaces (including Runnable) will
> > follow these
> >
> > specific paths.
> >
> > </p>
> >
> > @@ -114,7 +114,7 @@
> > <ol>
> >
> > <li>constructor <strong>as a consequence of
> > instantiation</strong></li>
> >
> > <li>contextualize</li>
> >
> > - <li>compose</li>
> >
> > + <li>service or compose</li>
> >
> > <li>configure</li>
> >
> > <li>parameterize</li>
> >
> > <li>initialize</li>
> >
> > @@ -143,11 +143,11 @@
> > <s2 title="Phases executed once">
> >
> > <p>
> >
> > These lifecycle methods are only called once in the entire
> > life of a
> >
> > - Component:
> >
> > + component:
> >
> > </p>
> >
> > <ul>
> >
> > <li>contextualize</li>
> >
> > - <li>compose</li>
> >
> > + <li>service</li>
> >
> > <li>configure</li>
> >
> > <li>parameterize</li>
> >
> > <li>initialize</li>
> >
> > @@ -169,9 +169,9 @@
> > 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 come to
> > temporary 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
> >
> > + 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
> >
> > only between a suspend() and a resume().
> >
> > </p>
> >
> > @@ -186,12 +186,12 @@
> > <s2 title="The Command Pattern">
> >
> > <p>
> >
> > The most advanced, most complicated and most flexible option
> > is to use
> >
> > - the Command pattern by having your Component implement the
> > Commandable
> >
> > + the Command pattern by having your component implement the
> > Commandable
> >
> > interface. This is experimental; you'll find the Commandable
> > and its
> >
> > related classes in the excalibur package.
> >
> > </p>
> >
> > <p>
> >
> > - It is recommended that if your Component implements
> > Commandable, it should
> >
> > + It is recommended that if your component implements
> > Commandable, it should
> >
> > not implement Executable or Interruptable. When you do choose
> > to combine the
> >
> > two, the order in which the different steps must happen is
> > very specific:
> >
> > <code>
> >
> > @@ -218,8 +218,8 @@
> > </p>
> >
> > <p>
> >
> > The advantage of using Commands is that you can have multiple
> > processes running
> >
> > - outside your Component that can manipulate it. These will run
> > until completion
> >
> > - even if you Component has already been disposed of.
> >
> > + outside your component that can manipulate it. These will run
> > until completion
> >
> > + even if you component has already been disposed of.
> >
> > </p>
> >
> > <p>
> >
> > You should note that the Command interface we use extends
> > Runnable, which means
> >
> >
> >
> >
> >
> >--
> >To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org> For additional
> > commands, e-mail: <ma...@jakarta.apache.org>
--
Cheers,
Peter Donald
-----------------------------------------------------------------------
| I thought there was a knob on the TV to turn up the intelligence. |
| There's a knob called "brightness", but it doesn't work. |
-----------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon/src/xdocs/framework
reference-the-lifecycle.xml
Posted by Leo Simons <le...@apache.org>.
On Sat, 2002-09-07 at 10:54, Paul Hammant wrote:
> Is everyone happy with this change?
>
> I have..
>
> 1) dropped the case of most usages of Component.
> 2) Refered to Serviceable where Composable was used solely.
+1
> It looks like Reserviceable is missing. There is a Recomposable. Thoughts?
We should I think mention that we the Re* interfaces are conceptually
sound but lack a solid contract or any implementation that supports
them, both in xdoc and in javadoc.
Just thoughts, no commits....sorry :/
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon/src/xdocs/framework reference-the-lifecycle.xml
Posted by Paul Hammant <Pa...@yahoo.com>.
Is everyone happy with this change?
I have..
1) dropped the case of most usages of Component.
2) Refered to Serviceable where Composable was used solely.
It looks like Reserviceable is missing. There is a Recomposable. Thoughts?
Regards,
- Paul
>hammant 2002/09/07 01:49:26
>
> Modified: src/xdocs/framework reference-the-lifecycle.xml
> Log:
> Words on Serviceable
>
> Revision Changes Path
> 1.4 +25 -25 jakarta-avalon/src/xdocs/framework/reference-the-lifecycle.xml
>
> Index: reference-the-lifecycle.xml
> ===================================================================
> RCS file: /home/cvs/jakarta-avalon/src/xdocs/framework/reference-the-lifecycle.xml,v
> retrieving revision 1.3
> retrieving revision 1.4
> diff -u -r1.3 -r1.4
> --- reference-the-lifecycle.xml 5 Aug 2002 13:23:59 -0000 1.3
> +++ reference-the-lifecycle.xml 7 Sep 2002 08:49:26 -0000 1.4
> @@ -14,9 +14,9 @@
> <body>
>
> <s1 title="Introduction">
>
> <p>
>
> - A Component lives within something called a container. The contract between a
>
> - container and a contained Component is simple: the container is required to
>
> - take a Component through what is called its <strong>lifecycle</strong>.
>
> + A component lives within something called a container. The contract between a
>
> + container and a contained component is simple: the container is required to
>
> + take a component through what is called its <strong>lifecycle</strong>.
>
> </p>
>
> <p>
>
> The Avalon project provides an
>
> @@ -37,9 +37,9 @@
> </s1>
>
> <s1 title="The Lifecycle">
>
> <p>
>
> - The lifecycle of a Component specifies the methods that can be called on it,
>
> + 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 its lifecycle, others may
>
> be called multiple times. These methods are called the lifecycle methods.
>
> </p>
>
> <p>
>
> @@ -51,14 +51,14 @@
> </s1>
>
> <s1 title="The Lifecycle interfaces">
>
> <p>
>
> - A Component exposes its lifecycle methods by implementing the lifecycle
>
> + A component exposes its lifecycle methods by implementing the lifecycle
>
> interfaces. Each of these defines one or more methods that represent a
>
> - specific Phase in a Component's lifecycle. The defined interfaces are:
>
> + specific phase in a component's lifecycle. The defined interfaces are:
>
> </p>
>
> <ol>
>
> <li>LogEnabled</li>
>
> <li>Contextualizable</li>
>
> - <li>Composable</li>
>
> + <li>Serviceable (replacement for Composable)</li>
>
> <li>Configurable</li>
>
> <li>Parameterizable</li>
>
> <li>Initializable</li>
>
> @@ -74,37 +74,37 @@
> <note>
>
> <strong>Note:</strong>java.lang.Runnable has also been in use as a lifecycle
>
> interface. This is not recommended and is not supported by Avalon. Instead,
>
> - the run() method is the responsibility of the Component itself. If you wish
>
> + the run() method is the responsibility of the component itself. If you wish
>
> to use it, call it from within start() or another method.
>
> </note>
>
> </s1>
>
> <s1 title="Phase order">
>
> <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
>
> + While none are required (it is possible to have a component implementing
>
> none of the lifecycle methods, although the use of that would be limited),
>
> some can only be used when others are as well. This is best explained using
>
> a few examples.
>
> </p>
>
> <s2 title="simple examples">
>
> - <p>The lifecycle of a <code>Component</code> implementing only Configurable for
>
> + <p>The lifecycle of a component implementing only Configurable for
>
> example will be:</p>
>
> <ol>
>
> <li>constructor</li>
>
> <li>configure</li>
>
> <li>finalize</li>
>
> </ol>
>
> - <p>The lifecycle of a <code>Component</code> implementing only Composable will be:</p>
>
> + <p>The lifecycle of a component implementing only Serviceable will be:</p>
>
> <ol>
>
> <li>constructor</li>
>
> - <li>compose</li>
>
> + <li>service</li>
>
> <li>finalize</li>
>
> </ol>
>
> </s2>
>
> <s2 title="complete">
>
> <p>
>
> - If a <code>Component</code> implements more than one interface the order of
>
> - the events (compose, configure etc.) follow a specific order. A Component
>
> + If a component implements more than one interface the order of
>
> + the events (service, configure etc.) follow a specific order. A component
>
> implementing all above interfaces (including Runnable) will follow these
>
> specific paths.
>
> </p>
>
> @@ -114,7 +114,7 @@
> <ol>
>
> <li>constructor <strong>as a consequence of instantiation</strong></li>
>
> <li>contextualize</li>
>
> - <li>compose</li>
>
> + <li>service or compose</li>
>
> <li>configure</li>
>
> <li>parameterize</li>
>
> <li>initialize</li>
>
> @@ -143,11 +143,11 @@
> <s2 title="Phases executed once">
>
> <p>
>
> These lifecycle methods are only called once in the entire life of a
>
> - Component:
>
> + component:
>
> </p>
>
> <ul>
>
> <li>contextualize</li>
>
> - <li>compose</li>
>
> + <li>service</li>
>
> <li>configure</li>
>
> <li>parameterize</li>
>
> <li>initialize</li>
>
> @@ -169,9 +169,9 @@
> 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 come to temporary 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
>
> + 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
>
> only between a suspend() and a resume().
>
> </p>
>
> @@ -186,12 +186,12 @@
> <s2 title="The Command Pattern">
>
> <p>
>
> The most advanced, most complicated and most flexible option is to use
>
> - the Command pattern by having your Component implement the Commandable
>
> + the Command pattern by having your component implement the Commandable
>
> interface. This is experimental; you'll find the Commandable and its
>
> related classes in the excalibur package.
>
> </p>
>
> <p>
>
> - It is recommended that if your Component implements Commandable, it should
>
> + It is recommended that if your component implements Commandable, it should
>
> not implement Executable or Interruptable. When you do choose to combine the
>
> two, the order in which the different steps must happen is very specific:
>
> <code>
>
> @@ -218,8 +218,8 @@
> </p>
>
> <p>
>
> The advantage of using Commands is that you can have multiple processes running
>
> - outside your Component that can manipulate it. These will run until completion
>
> - even if you Component has already been disposed of.
>
> + outside your component that can manipulate it. These will run until completion
>
> + even if you component has already been disposed of.
>
> </p>
>
> <p>
>
> You should note that the Command interface we use extends Runnable, which means
>
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>