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: More "academic" ideas [Was: [VOTE] New sandbox project]
Date Thu, 11 Mar 2004 14:06:13 GMT

> -----Original Message-----
> From: Hamilton Verissimo de Oliveira (Engenharia - SPO)
> [mailto:hamilton.oliveira@agenciaclick.com.br]
> Sent: Thursday, March 11, 2004 9:04 AM
> To: Avalon Developers List
> Subject: Re: More "academic" ideas [Was: [VOTE] New sandbox project]
> -----Mensagem original-----
> De: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> > Since the Avalon 4 spec clearly states the order in which
> > the lifecycle stages are performed, it makes no sense to
> > allow the user to change the order for an A4 component.
> >
> > I'm a fan of:
> >
> >  + order of additions of aspects doesn't matter
> >
> >  + all aspects are optional and independent
> >
> >  + it is hard to get a damaged configuration
> >
> >  + it is obvious what effects an addition has
> Sure. But this is not another "one man show" so we have to reach a common
> opnion.

The reason I thought about "order matters" was to make it easier to custom
lifecyles to be added (ie- lifecycle extensions).  Currently lifecycle or
stage extensions usually end up being run after something like
"initialize()" but that was never clarified in the exalibur-lifecycle

I agree that a consistent and reliable lifecycle execution order is
important, but it would be nice for "advanced" users to tweak that if they
wanted to.  Perhaps there could be an aspect that managed the lifecycle
"chain-of-command" and it would be in this aspect users could manage custom

This isn't a matter so important to me that I'm going to hold up any
existing work.  I just wanted to throw the thought out there to be

J. Aaron Farr
  (724) 696-7653

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

View raw message