commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: The exegesis
Date Mon, 12 Aug 2002 20:11:08 GMT
More fuel for the fire:

1.  discovery is a (functional) pattern...
2.  discovery provides component life-cycle support (SingletonService)...

which, of course, raises the obvious question:  should it?  How many 
life-cycle interface does a component have to implement??

One way to resolve this (with a [small :-] cost) is to allow life-cycle 
support to be pluggable... anyone want to take a stab at this? :-)

I find this humorous only because it's starting to sink in...


Richard A. Sitze
IBM WebSphere WebServices Development

Nicola, (Berin),
A little while back you suggested that I might help clarify the boundaries
between Avalon and Commons. Well I have, but maybe only in my own mind...

I think there is pretty much agreement on the following:
- Avalon defines component lifecycle interfaces
- Commons should not define component lifecycle interfaces

The key word is 'component'.

Javadoc for 'Initializable' from Avalon:
"Initialialize the component. Initialization includes allocating any
resources required throughout the components lifecycle."

Javadoc for Avalon framework package:
"The Framework part of Avalon contains interfaces and contracts 
those interfaces, along with default implementations of some of those
interfaces. Among other things, these interfaces impose a COP development
model. "

These two pieces of javadoc, IMO, explain why Avalon is good, but also why
lots of people don't use it. Avalon is about a COP development model. Its
interfaces help define that. But there is also documentation and other
best-practice that goes beyond actual Java code. That's great. But none of
that has anything to do with commons. And is why commons will never depend
on Avalon.

What I would like to do with [pattern] is define common method signatures.
These can be used by _any_ object, not just by components. They do not
specify an order. They do not require a container. They are, in essence,
meaningless (as opposed to Avalon, where each interface has great 
This is the great leap of faith for an Avaloner like yourself. Can you
accept that a method signature, such as initialize(), can standalone?

> Niclola wrote:
> There is NO TECHNICAL NEED of having interfaces like these.

Actually thats half the point. No, I'm not mad! And maybe its just a
different programming style to yours. My argument is that Initializable in
[pattern] has no baggage, no implications, no significance, nothing. Its
just a suggestion for a method name. On the other hand, Initializable in
Avalon requires COP, and thus associated issues.

Initializable in Avalon is thus a specialism of the generic Initializable 
[pattern]. But a specialism that adds COP semantic meaning. It gives you 
technical benefits (well virtually none - there would probably be a 
adaptor in [pattern]).

(BTW, I'm a realist. I don't actually expect Avalon to suddenly go out and
change its interfaces to extend [pattern]. Yet.)

My idea of [pattern], outlined above, is radical. And so is the 
to Avalon.


BTW: Ask yourself why [pattern] can have Resetable, but not 
There's no difference.

From: "Nicola Ken Barozzi" <>
> Stephen Colebourne wrote:
> > 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 : 
> >>>Framework should be in Commons
> >>
> >>I haven't followed either, but just explain the above - why should
> >>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
> Avalon folks *HAVE* lifecycle in Avalon.
> Before Commons came along, Avalon *was* the Java Apache Commons.
> > - 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
> > a particular set of interfaces that mean VERY precisely defined things
in a
> > contract that works ACROSS interfaces. When I talk about putting
> > type interfaces in [pattern] I mean interfaces that are INDEPENDENT of
> > another, not part of a framework.
> >
> > Is there really something scary about saying that if a class can be
> > initialised then the method name should be initialize()?? As a
> > interface?
> Useless and confusing.
> There is NO TECHNICAL NEED of having interfaces like these.
> > What if the lifecycle type interfaces were in [pattern] ??  The Avalon
> > interfaces still exist - they extend the Commons version not to add
> > methods, but to add the cross-interface lifecycle contract that is at
> > heart of Avalon.
> >
> > Re-read that last paragraph. Then read it again.
> You read it, and try to understand.
> Why the heck should we extend the Commons version?!?!
> Tell me a TECHNICAL need. A REAL one though.
> > If you understood it then everyone should be happy.
> > - Lifecycle, as a framework, is in Avalon.
> > - Lifecycle pattern interfaces are in [pattern].
> Gee, if you need them, go ahead and do them, but you will keep getting
> -1s from me and probably the rest of the world.
> You need those interfaces.
> --
> Nicola Ken Barozzi         
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message