avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [POA] How to work towards A5
Date Sat, 15 Jun 2002 13:57:07 GMT

Berin Loritsch wrote:
> In order to focus our energies on A5 without spinning our wheels on
> certain
> things, I suggest we take a look at the A5 proposal directory in CVS.
> For
> those who don't know it is in ${jakarta-avalon}/src/proposal/avalon5/.
> I propose that we go through, package by package to determine if there
> are
> any changes that need to be made.  With that said, I also propose that
> we
> save the component package for last as that is the one with the most
> controversy.

Thanks Berin for this thread. Most appreciated :-)

> Here are the design constraints we should work with:
> * Make things easier for the user of the framework--not harder
> * Provide a compelling reason to move forward
> * Provide a compatibility layer so that the progress of moving from
>   A4 to A5 is seemless (i.e. package naming changes).
> * Solidify the contracts between the container and the component


> As of right now, there are things that surround A4 design that we need
> to
> look at.  Some of them have been thorns in our side for some time now,
> but
> this provides the mental framework of what we are trying to solve.
> * Mixing of certain concerns
>   - The component lookup mechanism (ComponentManager/ComponentSelector)
>     mixes the concern of lookup and explicit release.  No other known
>     lookup mechanism requires you to release resources back to it.
>     + We need to determine if these concerns need to be mixed for
> practical
>       reasons.
>     + If not, we need to determine how to address pooled components
> without
>       an explicit release satisfactorily
>   - The definition of role/subrole was handled by two different
> entities,
>     and we need to merge that into one.
>     + Noone was truly happy with the ComponentSelector (something that
>       attempted a unified way of selecting subroles within a major
> role).
>     + The plumbing of default role and remapping of sub roles was
> removed
>       from the container--which is a container concern


Shall we make all of these a separate thread to focus on?
Lie [A5-1] Lookup-Management; [A5-1] Pooling, etc...

> * Container contracts insufficiently defined
>   - There are several different containers in Excalibur and Phoenix.
> All
>     of them have different meta-models and different rules for defining
> the
>     component's lifestyle and role mapping.
>     + The existence of different meta-models mean that the containers
> are
>       only _partially_ compatible.  The developer is responsible for
> rewriting
>       the meta data to make the component work in each container.  Not
> optimal.
>     + The meta models need to provide enough information for the
> container to
>       make decisions but not so much that it artificially constrains the
>       container.


>   - Lifecycle is very well defined, but do we need to add any lifecycle
> stages?
>     + What about component persistence (working dataset, runtime
> configuration
>       changes).
>     + What about a planned way of adding in new application specific
> lifecycle
>       methods?

Very important for my project and for James, which is starting now to 
define the new Mailet API. Let's hope Paul and I succede in showing the 
community the strenghts of Avalon.

>       - Some have identified this as a need, and have either already put
> effort
>         into it or are willing to.
>       - Such changes render the component that uses the new lifecycle
> stages
>         backwards incompatible--hense the need to extend the container
> at the
>         framework level.

- Exception handling
   + Runtime vs Exceptions
   + Proper rules for Exception handling
   + System to notify the system of things (move Notifying from Cocoon 
to Excalibur)

- Add a GUI-Web interface for management and programming with Avalon.

- Refer to the containers as reference implementations, and give ready 
to use containers.

- have fun! :-)

Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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