avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Date Wed, 20 Nov 2002 20:07:55 GMT


> I do not believe it is necessary to make the containers we have
> at anything other than
> Avalon-Framework-Interface level.  If we strive for compatibility on
> component-lacing (XML,
> properties, whatever) we will find some other team does not honor the
> chosen lacing team an
> delivers a container with a twist.  This could be BEA, Pramati, JBoss,
> Catalina, OpenEJB, Lutris.
> It could be some University in Bangalore or Manila.  We cannot contain
> container landscape;
> we'd be foolish to try.  There are thing people are imagining now that
> will impress the socks off
> us when released.
> Better to concentrate on our core product -> Avalon Framework's
> interfaces.
> Embrace the multi-container world!!

The "interfaces define everything" mentality is something that some
consumers of Avalon (myself included) find troubling.  Avalon Framework
needs to (and in quite a few cases does) include conceptual
documentation that goes beyond the interfaces.

Interfaces do not define anything save interfaces.  It's the contracts
behind those interfaces that matter.  Without the contracts, the
interfaces are meaningless.

Consider an Avalon Framework with all the lifecycle interfaces, but no
lifecycle definition.  It would be useless - containers would be able to
implement lifecycle methods in any order they desired.  You couldn't
write a container-independent application using such an Avalon
Framework.  It is the lifecycle contract that is fundamental.

In addition, by focusing on the contract it is most easy to see
inadequacies in the framework.  For example, the Context interface is
sufficient for the needs of consumer apps.  While it might be nice to
have some syntactic sugar as in the Phoenix Block Context, it isn't
strictly necessary.  However the contract is clearly incomplete -
without some sort of definition of container-common context objects and
their keys no one can use the Context in a container independent way.

For example, James, which is a pretty simple app from an Avalon
perspective, would not be able to run in any random Avalon container
that implemented the current Avalon Framework.  That's because James
needs the application home directory to resolve some of the file URLs.
But since the key ("app.home") and the semantic meaning associated with
the value returned (the application home as a File object) are not
defined as part of the contract, a random container doesn't need to
provide this.  As I understand it Phoenix and Merlin both provide this,
but it is not laid out explicitly in the Framework.

I'd argue that a standard, minimal set of keys/object should be part of
the Context contract. Otherwise the Context interface is fairly useless
as part of framework since every container would provide a purely custom
set of keys/values.  Thus any code written that implemented
Contextualizable would be implicitly container dependent.  There may be
other ways to address this problem, and that's what I'd like to see
discussed.  This issue is obvious when one thinks about the contract,
but is invisible when just considering the interface.

This is only one Avalon Framework issue among a number that need to be
discussed, clarified, and resolved.  Clarification of these issues will
make it easier, not harder, to develop new containers.

The only way to get a truly multi-container world is precisely to be
crystal clear about what the Avalon Framework does and does not
guarantee.  I very much support multiple containers - and the ability of
Avalon Framework consumers to write functional, container-independent


To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message