commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: Core architecture [was: Commons architecture]
Date Mon, 24 Jun 2002 08:19:10 GMT
Avalon is the project that works also to define common interfaces for 

Commons is about common packages.

This "core" discussion could as well be seen as an attempt to recreate 
here what Avalon wants to do, but as an Avalon committer, I think it's 
not the case.

If we take the word "framework" away from the proposal and instead focus 
on specific "API"s, I think it would be great.
If we talk about frameworks and patterns, there is Avalon.

Avalon is the "commons" of the Apache Server Framework, as of our charter.

Ola Berg wrote:

> A list with a few examples:
> transformation - general interface for object transformation


Morphos is an attempt to start such a thing.
Call it morphos, call it transformation, I'm +1.

> type conversion - special application of transformation
> conversion from and to String - special and useful application of type conversion.
> object instantiation - factories and other patterns for instantiation. This is actually
related to transformation.

This is about patterns, and I don't see a need for specific APIs.
Interoperability here is not needed, unless working in a true component 
framework, and that's Avalon.

> pooling - supports different pools and pooling policies. This is dependent on instantiation

Again, if we talk about a common package for pooling, ok, but keep the 
"framework" stuff in mind.

> config - the pattern \"Object recieves config data\" is already present in Avalon. 
> My idea of \"Configurator configures objects out of config data and keeps
> track of state, persistance and updates\" (related to pooling and 
> factories and type conversion) is not present anywhere else than in my 
> nu.viggo.* classes from what I have seen.


Avalon does not work as you say. What you call Configurator is in fact 
the container of the components, and it does keep track of all these.

> assertions - related to all issues of type safety in all
 > packages, esp type safe collections in Commons Collection.

This +1.
It's a general utility package.

> younameit - (Jon, tell us about your ideas, chances are that we have been thinking along
the same lines) 
> Some of these might actually be better off in a separate project (so that the scope doesn\'t
grow to much), but one can easily see that there are some common interfaces that some classes
need to implement in order to acheive this inter-operability between packages.

> I support the idea of collecting the really general interfaces 
> (Identifiable, Resetable etc) in a package of its own.

If these interfaces are marker interfaces, they have no use.

If they are part of a framework, defining them out of a framework will 
not work.
Avalon Framework is the place for it.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message