avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Farr, Aaron" <Aaron.F...@am.sony.com>
Subject RE: [RT] container extensions
Date Tue, 01 Jul 2003 15:20:29 GMT

> -----Original Message-----
> From: Leo Simons [mailto:leosimons@apache.org]
> > Currently we have lifecycle extensions, but these are not yet supported
> by
> > Phoenix.
> patches welcome though!

I'll look into this.  There's a set of patches I've been working on for
Fortress that would allow easier configuration of lifecycle extensions too.

> For those of you who do not like examples, some complex prose...
> It is very difficult to predict in advance where the vector of change
> for container architecture internals lies, since many modifications to
> those internals are domain-specific. Hence we must strike a balance
> between type safety and flexibility. Maximum flexibility is gained
> through utilizing container internals that use "flexibility patterns"
> like interceptors, pipelines, events, scripting and declarative assembly.

My current approach has been looking at domain specific extensions, ie-
lifecycle extensions, assembly extensions.  The new deployment stage
extensions in merlin basically allow you to get a hold of the Appliance, but
even that may be exposing more than would be desirable.

You're correct though in that it's difficult to strike the right balance.

> The root of the problem here is that no agreemnt exists between the
> containers about how much their contexts need to provide. Like "part of
> the container-component contract is that the container will provide a
> 'working directory' to the component on request, and that this working
> directory will be available through the context".

True and I think this is exactly what is needed:  a container-component
contract on standard context values and a context extension API.

I've been meaning to add a page in Wiki that reviews in more detail how the
three containers handle contexts.  Seeing everything side by side might help
point out a solution.


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

View raw message