You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Mark Woon <mo...@SMI.Stanford.EDU> on 2002/03/06 00:23:05 UTC
Roles and shorthand names
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.
Am I missing something? What is the the proper way to solve this?
Thanks,
-Mark
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Roles and shorthand names
Posted by Stephen McConnell <mc...@apache.org>.
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:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Roles and shorthand names
Posted by Mark Woon <mo...@SMI.Stanford.EDU>.
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 javadoc for CascadingConfiguration in the scratchpad sounds like it'll do
what I need. How exactly do you define a parent configuration? 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.
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)?
Thanks,
-Mark
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Roles and shorthand names
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: woon@SMI.Stanford.EDU [mailto:woon@SMI.Stanford.EDU]On Behalf Of
> Mark Woon
> Sent: Wednesday, 06 March, 2002 00:23
> To: Avalon Developers List
> Subject: Roles and shorthand names
>
>
>
> 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.
Cheers, Steve.
> Am I missing something? What is the the proper way to solve this?
>
> Thanks,
> -Mark
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>