At 08:30 28/2/01 -0800, Craig R. McClanahan wrote:
>I haven't followed every message of every day on Avalon's mailing lists,
and it
>has been a couple months since I dived in last time (you guys talk a *lot*
:-),
>but the overriding image I always got of the vision for Avalon was:
>* A framework for building servers, and
>* A set of services preconfigured to this framework's APIs
yep this is the phoenix/cornerstone parts of Avalon that will eventually be
split off ;) (if by framework for building servers you mean the kernel in
which servers will be hosted).
>If AbstractFoo means that the class is abstract in the Java sense (i.e.
you have
>to subclass it and implement some methods to make it useful), then you are
not
>seeing the value of the framework-independent shared library components as
highly
>as I am. Make it ConcreteFoo/DefaultFoo and I would be much happier :-)
I agree - however there has never been any motivation to do so in the past
as I was effectively my own client ;) What I would prefer to do is
AbstractFoo <--extends-- JavaBeanStandardFoo <--uses-- MyFrameworkWrapperFoo
or more simply (and better)
JavaBeanStandardFoo <--uses-- MyFrameworkWrapperFoo
>Just as an example, let's consider our favorite whipping boy -- database
>connection pools. It makes a lot of sense to have a "pure JavaBeans"
version of
>a connection pool that does all the grunt work, but has no notion of
lifecycle or
>configuration -- it's up to the user to create the thing, initialize its
>properties, and so on.
agreed.
>It also makes perfect sense for Avalon to include a
service/wrapper/whatever that
>initializes a connection pool at the right time in a server startup, using
the
>Avalon approach to configuration and component lifecycles. Such a service
class
>would rightfully be packaged with the Avalon framework, and declare a
dependency
>on the shared component. Likewise, it makes sense for Struts to do the same
>thing -- include Struts-specific code (in Struts, not in the library) to
>initialize the connection pool at the right time, based on Struts notions
about
>configuration file formats and such. And so on and so on.
agreed. If by Avalon you mean The cornerstone part of Avalon ;)
>Trying to have Avalon play both roles (framework and component library) would
>seem to cause confusion, or the perception of "most favored nation" status in
>cases where conflicting goals between the using frameworks would argue for
>different APIs to the shared components.
possibly though I would hope not ;)
Personally I hope the component library encourages JavaBeans (or
equivelent) type access as primary importance. Other framework specific
access patterns (regardless whether they are turbine/avalon/struts/other)
should be discouraged and only allowed while the component is being
refactored. Once it hits release/stable/whatever status I hope/believe
JavaBeans will be dominant modelling paradigm (or something like Ant thats
is also relatively lightweight).
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
