Peter Courcoux wrote:
>Hi,
>
>I've been quietly reading the user and dev lists for a week or two and
>am now getting my brain round my first trivial components. Many thanks
>to Berin for "Developing with Apache Avalon". It makes a lot of sense
>and has helped considerably in understanding the principals.
>
>I have struggled a bit with the 'ContainerComponent' and
>'ComponentManager' part of 'Implementing the Dream'. I am only slowly
>beginning to see how these actually fit into an application. It is
>relatively clear what they do, I think, just not clear to my very slow
>mind what best practice is in using them.
>
Think of the following two things:
* a container - something that manager the establishment and
deployment of a componet
* a compoent - a managable object that has a well defined lifecycle
Then think about the communication between a container and a component -
a number of utilities are used by a container to supply information and
resource to the component it is managing. These include things like a
configuration, a context object, and a service manger or component
manager - in fact it is more correct to think of the class ServiceManger
as a ServiceLocator - bacuase in actual fact it doesn't do any mangement
at all - it's simply a holder of the service that a componet needs. The
real management is in the container.
>
>If a re-usable component itself uses components, in addition to
>implementing its work interface it needs to also be a container to be
>able to obtain the references to the components it needs. Is this
>correct?
>
Does not sound right ...
A component may have dependecies on services exposed by other compoents
and can itself publish service it provides. A componet that receives
service and uses these in the performace of the service it offers is not
a container - its simply a component with depedencies. If however -
that componet nneeded to build and deploy new components internally,
then you starting see container charachersitics in you component. For
example, the Merlin container is a componet. It a componet becuase it
can be managed as a classic compoent by a partent, it can have
depedecies, etc. - but it also manages the deployment of other components.
>
>I had wondered whether the 'work interface' should be kept separate from
>the 'container', but I think I am right in saying that this is not what
>the framework intends.
>
>
Work interface is not really a notion at the container level - this is a
component abstraction. I could define a componet that has logging,
configuration, serviceable, etc. and my interface could be the interface
AuditManager. The internal lifecycle interface (LogEnabled,
Configurable, Contextualizable, Initializable, Startable, Disposable,
etc.) are used by the container - but its the work interface that is
exposed. Some contains such a Phoenix expose componet via a proxy so
that the internal lifecycle interface are not accessible to clients
using the components service.
>If someone could either confirm my thoughts or put me on the right track
>I would be most grateful.
>
>One small point that confused me is the javadoc for the Serviceable
>interface. Am I correct that line 11 of the source should start 'A
>Serviceable' and not 'A Composable'?
>
>
Thaks for the update - I just fixed it the CVS.
Cheers, Steve.
>Many thanks.
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
