Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 73951 invoked from network); 6 Mar 2002 01:06:08 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 6 Mar 2002 01:06:08 -0000 Received: (qmail 21479 invoked by uid 97); 6 Mar 2002 01:06:14 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 21458 invoked by uid 97); 6 Mar 2002 01:06:14 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 21447 invoked from network); 6 Mar 2002 01:06:13 -0000 From: "Stephen McConnell" To: "Avalon Developers List" Subject: RE: Roles and shorthand names Date: Wed, 6 Mar 2002 02:07:37 +0100 Message-ID: <00b601c1c4ab$4e6d9260$0a01a8c0@osm.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <3C856482.938DA002@smi.stanford.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Mark Woon wrote: > > Stephen McConnell wrote: > > > > If I have multiple components that have the same configuration needs > > > (ie. a 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 and 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: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: