commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: The exegesis
Date Mon, 12 Aug 2002 15:03:27 GMT
> From: Stephen Colebourne [] 
> From: "Geir Magnusson Jr." <>
> > On 8/11/02 6:26 PM, "Vincent Massol" <> wrote:
> >
> > > I haven't been following the discussion, but I agree with you : 
> > > Avalon Framework should be in Commons
> >
> > I haven't followed either, but just explain the above - why should 
> > Avalon Framework be in commons?  Do the avalon people want it in 
> > commons?  Why don't they want it in Avalon?
> The views seem to be (generalising):
> - Avalon people want lifecycle in Avalon
> - Many commons people instantly -1 the moment 'lifecycle' is mentioned
> - I have said that lifecycle type interfaces COULD go in [pattern]
> There is a degree of confusion however. Lifecycle to an 
> Avalon person means a particular set of interfaces that mean 
> VERY precisely defined things in a contract that works ACROSS 
> interfaces. When I talk about putting lifecycle type 
> interfaces in [pattern] I mean interfaces that are 
> INDEPENDENT of one another, not part of a framework.

Danger Will Robinson! Danger!

Seriously, this is where you can learn from the experience of the
Avaloners.  It is quite common for component developers to take
advantage of the lifecyle sequence to set up their component to
be in a working state.  If you change the sequence of calling the
lifecycle interfaces, it breaks the component.

Avalon *used* to have the interfaces unrealated to each other, with
the exception that Initializable would always be called last.
Experience taught us that we needed to guarantee a specific order
of calling the interfaces.  By making them completely independent
of one another you end up increasing the time it takes to understand
how your stuff works as opposed to just using.

Avalon only has a steep learning curve because it is a jump from
OOP to COP.  Component Oriented Programming (COP) builds on OO
principles, but provides much stricter guidelines and has a Container
to instantiate and manage the components in a system.  Avalon is
not the only COP system out there.  Servlets and EJBs are also
examples of COP based systems.  Each Servlet is a component, as well
as each EJB.

> Is there really something scary about saying that if a class 
> can be initialised then the method name should be 
> initialize()?? As a standalone interface?

Hey we have that!  Why not just use it?  Why spend time and energy
relearning all the things we had to figure out?

> What if the lifecycle type interfaces were in [pattern] ??  
> The Avalon interfaces still exist - they extend the Commons 
> version not to add extra methods, but to add the 
> cross-interface lifecycle contract that is at the heart of Avalon.
> Re-read that last paragraph. Then read it again.

Avalon Framework is a collection of interfaces.  We have a logger
abstraction (no auto discovery of loggin implementation--that is
the responsibility of the container), we have configuration,
component lookup, Initializable, Disposable, Startable, Suspendable,
and more.  However, these interfaces *ARE* Avalon Framework.
Anything more is in documentation, or in the containers we have in
Excalibur and Phoenix.

By placing the lifecycle interfaces in Pattern, you are effectively
moving Avalon Framework--or duplicating it in Pattern.  What is
dangerous is not their existence, but the lack of consistency in how
they are applied.  You will find that you *need* to specify a common
ordering so that you can properly build the tools to manage your

> If you understood it then everyone should be happy.
> - Lifecycle, as a framework, is in Avalon.
> - Lifecycle pattern interfaces are in [pattern].

You are proposing to move all the interfaces--or duplicate existing
interfaces into Pattern.

Why not have Pattern *use* the *existing* interfaces in Avalon?
Oh yeah, I forgot--it's that political thing.

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message