Leo,
Many thanks, but it doesn't seem right dragging you away from the Beer
and festivities :-)
On Sat, 2002-08-17 at 21:12, Leo Simons wrote:
> On Sat, 2002-08-17 at 13:21, Peter Courcoux wrote:
> > Steve,
> >
> > Many thanks for the detailed reply. More questions below :-(
>
> he does make it sound rather complex, doesn't he ;)
Yes, but he got me there in the end, thats good going ;-)
>
> > > >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
> >
> > So if I am writing an application and I have a number of services which
> > I wish to have available, I do so by including them all in a container
> > which is responsible for lifecycle management and my application uses a
> > service by obtaining a reference to it. So in this case all the
> > application logic is kept away from the container.
>
> yup. Avalon is not about application logic at all. It is about just
> about everything else =)
Where I went wrong was in trying to see how I could make a component of
things that shouldn't really be components, but ordinary classes. That
said, some of the principals do, with care, travel well.
>
> > > * a compoent - a managable object that has a well defined lifecycle
> > Understood.
> >
> > > 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.
> > >
> > This makes sense.
> > > >
> > > >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?
>
> nope. the term we use for a component that references other components
> is "composable"/"servicable".
>
I understand this. I was looking from a totally incorrect perspective.
All clear now!
> > Ah....
> >
> > Presumably a component that uses the services of other components
> > obtains the references for the required services from the container. So
> > the order of initialization of the services by the container is
> > important if there are dependencies.
>
> yup.
>
> > But a component can instantiate and manage its required services if for
> > some reason it is not appropriate to obtain them from the 'container'.
>
> yup. This is not neccessary very often. When it is, you'd usually extend
> or embed an existing container. Some of the avalon container
> implementations (I think only fortress atm) also provide support for
> 'container hierarchies' to solve these issues.
OK.
>
> > > >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.
>
> IOW, what we call the "work interface" is often distinctly separate from
> the "lifecycle interface". In 70% of cases (I guess), what you do is
> this:
>
> /** work interface */
> interface MyService extends MultipleLifecycleInterfaces
> {
> /** work interface method;
> only valid between start() and stop() */
> myBlah();
>
> /** another work interface method;
> only valid between start() and stop() */
> myBlaat();
> }
>
> /** component */
> class MyServiceImpl implements MyService
> {
> }
>
> What we usually do consider as a part of the "work interface contract"
> is the role. ie you'll often see:
>
> /** work interface */
> public interface MyService extends MultipleLifecycleInterfaces
> {
> final static string ROLE = "com.foo.bar.app.MyService";
>
> // ...
> }
>
This makes sense and it was trying to reconcile this with an
inappropriate view of a Component that was causing my problem from the
start. (see above under OK)
> There are often additional constraints placed on the lifecycle. Some
> containers (ie Merlin) allow you to define these using some formal
> method. It is good to javadoc these regardless of whether they do or
> not. ie:
>
> /** work interface */
> public interface MyService extends Contextualizable
> {
> // ...
>
> /**
> * This Service requires that the context contains at least
> * the following keys / values:
> *
> * key value type value contents
> *
> * blah String URL for jadajada
> * dtd DTD the object rep. of the DTD for
> * jadajada
> * tree Node the tree to parse
> */
> public void contextualize( Context c)
> throws ContextualizationException;
>
> // ...
> }
>
> I think you already got all that but some people reading along might've
> wondered; hope this clarifies some stuff ;)
>
Confirms that Steve put me on the right track and adds a few pearls. It
is definitely a great help.
Thanks to all. Now to put it into practice!
Peter
> cheers,
>
> Leo
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Peter Courcoux
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
