avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <mcconn...@apache.org>
Subject RE: Roles and shorthand names
Date Wed, 06 Mar 2002 01:07:37 GMT

Mark Woon wrote:
>
> Stephen McConnell wrote:
>
> > > If I have multiple components that have the same configuration needs
> > > (ie. a <dbpool> parameter), what's the best way to set up the
> > > configuration for these components?  Right now, I'm writing separate
> > > configuration blocks for each.  It would be nice if I could have the
> > > different components use the same configuration block.  However, since
> > > these components have different roles, I must assign them separate
> > > shorthand names.
> >
> > This isn't an answer - just a comment.  I'm currently working on
> > getting a clean separation of some of these notions as part of the
> > service package and resolution of a viable mechanisms for defaults
> > all the up the chain form class meta-info up, through profiles
> > describing available named instantiation configurations, to roles
> > reflecting service instance deployment.
>
> You're refering to your CascadingConfiguration work?  I knew I
> should have paid more attention when you were discussing that
> problem...  ;)

The CascadingConfiguration is the key enabling mechanisms through which
defaults can be propergated up the chain.

> The javadoc for CascadingConfiguration in the scratchpad sounds
> like it'll do what I need.  How exactly do you define a parent
> configuration?

The parent is just any old configuration instance derived from (a)
a configuration loader from file, (b) supplied under configure,
(c) resolved through config.getChild, etc.  Once you have your
defaults, and your primary configurations, create a new compound
configuration using:

   Configuration config = new CascadingConfiguration( primary, parent );

> As I understand it, if I've two roles, RoleA and RoleB, with
> shorthand names A and B respectively, I'd assign both the same parent
> configuration.  I can then override the values of the parent
> configuration by defining configuration blocks <A/> and <B/> as
> necessary.  Otherwise, they'd just use the values from the parent
> configuration.

Exactly.

> BTW, are you planning on building on what you have here (which is an
> incremental change from what already exists), or are you
> envisioning something much grander (a change from the ground up)?

Kind of feeling my way.  Driving factors are a lot of difficulties using
Excalibur component manager stuff (due to the Object environment I'm
working in), and a desire for total simplicity in execution in that you
run a component and everything has a defaults - default instantiation
configurations, default association of role names to configurations,
as so on.  Your site configuration/assembly then becomes a question of
minor tuning of different values. In the process of solving these issue
I'm running into conflict with the Phoenix approach (which a reasonably
familiar with), and I'm aware of overlaps with some the Excalibur
content (which I'm not familiar with) - however, what I'm assuming is
that the total ease of use will be sufficient compelling that the
implementation and/or approach will end up as part of Phoenix/Excalibur/
Avalon framework evolution.  The ultimate objective is to lower the
barrier to good COP, higher take up of Avalon as a framework and finally,
drop-dead-easy deployment of production services under Phoenix.

Cheers, Steve.

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


--
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