avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Single Avalon Implementation yes/no/why/how ( Re: CVS organization )
Date Thu, 21 Nov 2002 05:06:13 GMT
> We do have a definition :-
> http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html
> I do accept that docs could be improved.

I believe that is Peter's point: a recognition that Java interfaces alone do
not define the entirety of the programming contract.  So as people begin to
focus again on cleaning things up, the contract needs to be (more) fully
documented for the benefit both of container users and container authors.

> > However the [Context] 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.

> Context is a base for [ServletContext], MailetContext,
> BeanContext (written for EOB), BlahContext.  Some of
> them may offer a 'get root dir' feature, some may not.
> Do we encode all permutations for Servlets, Mailets,
> Beans, Blocks, MerlinApps in the same file?

> The point is that Context is deliberately vague.

> Maybe we should have a single additional context method called
> getContainer().

Does it make sense to have some notion of a "context domain", such that we
can find out what domains are supported by a Context?  And even documenting
that some things are not part of a contract is valuable.  What is not useful
is just leaving everything undefined.

I look at it this way.  Context is a fairly abstract base class.  But due to
the design of the Frameworks, it is also the access point to the
functionality of its subclasses.  So we look for design patterns that can
help us out with this seeming conflict.  We already know what to do when
functionality is statically embodied by extend/implement.  In the case of
keyed data, perhaps having keys that tell us about contractually defined
keysets would be helpful.

Do you not see a value to an implementor having guidance for how to publish
a common notion, or a client knowing how to look for a common notion?  From
my perspective, the goal is to ensure that if a semantic is provided, it is
provided in a common fashion.

	--- Noel


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


Mime
View raw message