On Thu, 3 May 2001, Michael L. Heuer wrote:
>
> apologies if this is seen as trolling, but aren't there implementations of
> logging kits, thread and object pools, and other goodies, all nicely
> wrapped in 'Separation of Concerns' interfaces allowing for maximum
> pluggability and configurability of a system, already in the jakarta
> Avalon project?
>
> > http://jakarta.apache.org/avalon/framework/api/index.html
>
> michael
>
>
>
There definitely are -- as Peter Donald never hesitates to point out :-).
However, if you look at the code itself, it's the "wrapped in 'Separation
of Concerns' interfaces" that causes one to pause. To use these classes,
you have to buy into Avalon as a *framework*, not just as a source of
components. If you are going to use Avalon anyway, that's a great
convenience -- if you're not, then you are faced with having to deal with
configuration and lifecycle issues differently for the Avalon-originated
components versus the others.
One of the key acceptance criteria for packages into Commons is "no
dependence on frameworks." The idea is that you should have zero
assumptions about configuration (use JavaBeans properties instead) or
lifecycle (that's the responsibility of whatever framework you use), so
that these packages can be used inside *any* framework.
As primary author of the Struts framework, my approach is going to be
this:
* Factor out the pieces of Struts that are framework-agnostic
into commons (assuming others like them -- they have liked my
initial beanutils and digester offerings :-).
* Modify Struts to depend on the Commons packages instead of the
internal versions.
* Take advantage of the improvements that others make to the common
packages, without having to do it all myself.
At the same time, there are zero assumptions in these packages about how a
connection pool is configured, or what the lifecycle of a thread pool is
-- those kinds of things can be created (in a framework) on top of
framework-agnostic parts instead.
Craig McClanahan
